Skip to main content
• 7 min read

THORChain Exploit: $10.7M Drained from
Asgard Vault via GG20 TSS Key-Material Leakage

THORChain lost about $10.7 million after a newly churned malicious node exploited a vulnerability in its GG20 threshold-signature implementation, reconstructed a single Asgard vault private key, and broadcast unauthorized outbound transactions before automated and manual halts contained the incident.

AUTOSEC.DEVAUTOSEC.DEV
THORChain Exploit: $10.7M Drained from Asgard Vault via GG20 TSS Key-Material Leakage
  • Incident Date: May 15, 2026
  • Target: THORChain Asgard vault / cross-chain outbound signing infrastructure
  • Target Overview: THORChain is a decentralized cross-chain liquidity network that uses Asgard vaults and threshold-signature signing to custody and route native assets across chains. The incident affected one Asgard vault, while THORChain later stated that the remaining vaults and the SOL pool were not affected.
  • Total Loss: ~$10.7 million in protocol-owned funds
  • Attack Vector: GG20 TSS Implementation Vulnerability / Progressive Key-Material Leakage / Malicious Churned Node / Unauthorized Outbound Transactions

Incident Review & Technical Details​

1. Attack Path​

  1. Malicious Node Entered the Active Set: THORChain's later incident report said a newly created node operator entered the network on May 13, 2026, with about 635,000 RUNE bonded across two addresses. The node was randomly assigned to one of the active Asgard vaults.
  2. Node Participated in Routine GG20 Signing: Over the next two days, the malicious node participated in normal GG20 threshold-signature ceremonies. In a healthy TSS design, each node should only hold a secret key share and should never reconstruct the full vault private key.
  3. GG20 Implementation Weakness Leaked Key Material: THORChain's investigation identified the leading root cause as a vulnerability in its GG20 TSS implementation that enabled progressive key-material leakage. This should be read as an implementation and deployment failure in the THORChain signing stack, not proof that every GG20 deployment is exploitable in the same way.
  4. Vault Private Key Was Reconstructed: Once enough key material was obtained, the attacker reconstructed the full private key for the targeted Asgard vault.
  5. Unauthorized Outbounds Bypassed Normal Signing: With the vault key reconstructed, the attacker signed and broadcast outbound transactions directly, bypassing the normal multi-party GG20 signing ceremony and THORChain's proactive signing checks.
  6. Loss Estimate Was Revised Upward: Early reporting described about $7.4 million in unauthorized outbounds. THORChain's later estimate revised the loss to approximately $10.7 million. The Record cited early blockchain-monitoring reports of more than 36 BTC, worth about $3 million, plus roughly $7 million in other assets.
  7. Automated Halt Systems Triggered: THORChain's reactive solvency checker detected vault-balance divergence within minutes and automatically halted signing and trading across multiple chains.
  8. Manual Governance Halts Completed Containment: Node operators then stacked manual pauses and used Mimir governance votes to halt trading, signing, chain observation, and churning. THORChain said the network reached a controlled halt within about two hours of the community alarm.

2. Impact Scope​

  • Direct Losses: Approximately $10.7 million was drained from a single Asgard vault.
  • Affected Asset Class: THORChain's first public statement said initial indications showed protocol-owned funds were affected and individual user swaps were not affected.
  • Affected Vault: THORChain's full report described the incident as affecting one vault out of five, with the remaining four vaults unaffected. Early announcements and media reports described the affected vault as one of six Asgard vaults, reflecting the early public state before the fuller post-incident accounting.
  • SOL Pool Scope: THORChain stated that the SOL pool was safe because EdDSA-based chains were not vulnerable to this class of GG20-related attack.
  • Node Penalty: Nodes securing the compromised vault were subject to bonded RUNE slashing after the unauthorized outbound transactions.
  • Network Operations: Trading, signing, chain observation, and churning were halted while the team investigated and stabilized the network. New chain onboarding and operations requiring churn were delayed.
  • Recovery Path: THORChain said patch v3.18.1 was released as an immediate protection step, while recovery of lost funds would be decided through community governance via ADR-028, with the selected approach expected for implementation in v3.19.

3. Root Cause Assessment​

The incident sits at the intersection of cryptographic implementation risk, validator churn, and emergency containment design:

  • TSS Was Treated as a Strong Custody Boundary: Asgard vaults rely on threshold signatures so that no single node can sign alone. Once the implementation leaked enough key material, that boundary collapsed for the targeted vault.
  • The Attacker Entered Through Normal Churn: The attacker did not need to compromise an existing operator if they could join as a valid node, bond RUNE, get assigned to a vault, and participate in signing rounds long enough to extract useful material.
  • Proactive Solvency Checks Were Bypassed: THORChain's proactive mode can refuse to sign a transaction that would make a vault insolvent, but the attacker signed transactions directly with the reconstructed private key. The protocol did not get a chance to reject the signing ceremony because the normal ceremony was no longer being used.
  • Reactive Monitoring Worked After the Drain: The solvency checker detected the imbalance quickly and triggered automatic halts. This reduced further damage, but it could only react after funds had already left the vault.
  • Emergency Governance Reduced Blast Radius: Manual pauses and Mimir votes helped stop trading, signing, chain observation, and churning, preventing the malicious node from cleanly exiting and blocking additional risky churn activity.
  • Shared Cryptographic Components Create Ecosystem Risk: THORChain temporarily withheld some technical details while warning other projects using the same GG20 cryptography to protect their systems. That is the right posture when exploit details may be reusable.

The core invariant should be strict: a validator that joins through normal churn must never be able to derive enough information from repeated threshold-signature participation to reconstruct a vault private key, and direct key possession should never be the only remaining barrier between an attacker and outbound asset movement.

4. Mitigation and Response​

Recommended actions for cross-chain vault networks, TSS custody systems, and validator-based protocols:

  • Treat GG20 and other TSS libraries as critical custody infrastructure requiring external cryptographic review, implementation review, reproducible builds, and version-pinned deployment.
  • Add explicit detection for abnormal signing-round transcripts, repeated abort patterns, unusual peer behavior, and key-share extraction attempts.
  • Limit exposure during churn by reducing the amount of value newly assigned nodes can help secure before they build operational trust and history.
  • Segment vault liquidity so a single compromised vault cannot expose a disproportionate share of protocol-owned funds.
  • Add independent watchers that compare expected vault balances with actual chain balances and alert on unauthorized outbound transactions before normal accounting delay hides the issue.
  • Keep automatic solvency checks, but pair them with pre-signing, signing-transcript, and post-broadcast controls so defense is not purely reactive.
  • Require node operators in affected vaults to preserve Bifrost logs, host telemetry, key-management logs, and signing-round evidence for coordinated forensic review.
  • Continue slashing and governance controls for nodes associated with unauthorized outbounds, but do not rely on slashing alone as an exploit deterrent when immediate loss can exceed bonded value or be routed quickly.
  • Publish a final post-mortem with affected vaults, transaction hashes, patch details, TSS failure mode, and regression tests once other potentially exposed projects have had time to patch.

AUTOSEC.DEV Solution: Building a 360-Degree Defense​

THORChain's incident shows that bridge security is not only about smart contract code. It also depends on cryptographic signing ceremonies, node lifecycle controls, monitoring, key management, and emergency governance operating as one system.

  1. TSS & Key-Management Review: AUTOSEC.DEV reviews threshold-signature implementations, signing transcripts, key-share handling, distributed custody assumptions, and upgrade paths from legacy signing schemes to modern alternatives.
  2. Cross-Chain Vault Security Audit: We test vault accounting, outbound authorization, liquidity segmentation, chain-specific signing flows, and failure modes where direct key possession bypasses normal protocol controls.
  3. Validator & Churn Risk Assessment: We examine node admission, bond sizing, assignment randomness, churn timing, slashing economics, operator telemetry, and controls for newly joined validators.
  4. Incident Response (IR): AUTOSEC.DEV supports rapid exploit reconstruction, fund-flow tracing, log preservation, node compromise analysis, emergency halt guidance, and post-incident hardening for active cross-chain incidents.

Service Content​

Reference​