THORChain Exploit Report #2

THORChain Exploit Report #2

On May 15, 2026, THORChain identified unauthorised outbound transactions from one of the network's vaults. The vault was paused, and approximately $10M was lost before the network could respond. No other vault was affected, and chains secured by a different signature scheme, including Solana, were not exposed at any point.

Following a careful review, the THORChain team has determined that this incident doesn’t fit the pattern of a typical DeFi exploit. It was not a smart contract bug, a bridge vulnerability, or an oracle manipulation, the categories that account for most incidents across the industry. Instead, it was a cryptographic attack targeting the threshold signing process that validators use to authorise transactions, built by combining three small, individually low-severity issues that had been present in the codebase since THORChain's early use of GG20.

This post-mortem is divided into several parts. We first walk through the overall pattern of the attack at a high level, then explain the underlying mechanics in detail. We then address why the exploit was contained to a single vault, including an explanation of why THORChain's automatic defenses did not intervene in this specific case. Finally, we outline why this incident required a different class of technical capability than most DeFi exploits, and the changes THORChain is implementing as a result. An appendix with a more detailed explanation and a glossary of terms used throughout is included at the end.

Overview

The attack can be explained through a succession of four steps that compromised the key signing. To begin with, the attacker joined the network as a normal validator. Nothing about this looked unusual. THORChain's validator set is permissionless by design, and anyone can churn into the network.

At setup, the attacker planted a flaw in their own key material. This is the part that required technical skill. Validators generate cryptographic material to sign transactions together, however the attacker built theirs in a way that looked valid but wasn't.

The attacker then deliberately failed a specific step (the round 2 or MTA) in the signing process, over and over, 864 times across two and a half days. Each failure looked like routine node flakiness, the kind that happens constantly across any validator set. But because of the flaw planted at setup, each failure also leaked a tiny portion of other validators' secret key material.

Once enough fragments had accumulated, the attacker held sufficient material to replicate the private key. In other words, the attacker could sign transactions alone, and the resulting signature was indistinguishable from one produced through the proper process. That's why the network's safeguards didn't intervene: there was nothing anomalous to catch.

The Detailed Explanation

Why THORChain validators sign together in the first place

No single validator holds the private key to a THORChain vault. Instead, the network uses a process called Threshold Signature Scheme (TSS), where a group of validators jointly compute a signature without any one of them ever holding or seeing the full private key.

THORChain's TSS implementation is based on a protocol called GG20, a well-studied and widely used design across the industry. However, it came with a specific weakness that ultimately enabled the attack.

Pailier, the lockbox at the center of it

To jointly compute a signature without revealing their individual secrets, validators need a way to do math on each other's secret numbers without actually seeing them. This is called a Paillier cryptosystem, named after the cryptographer who designed it.

Think of it as a special kind of lockbox: you can put a number inside, hand the locked box to someone else, and they can perform specific calculations on what's inside without ever opening it. When the result comes back out, it's correct, even though nobody except the original owner ever saw the actual number.

This lockbox is only secure if it's built correctly. It depends on a number called a modulus, built by multiplying two large secret prime numbers together. A number that’s the product of two large primes is called a biprime. The security of the entire lockbox rests on the fact that biprimes are extremely hard to break back down into their two original primes, even with enormous computing power. This is the same basic idea that secures a huge amount of internet encryption today.

What the attacker actually built, and why

To understand this attack, it helps to first understand what the attacker was trying to achieve before looking at how they pulled it off.

The attacker's goal was never to break into someone else's lockbox from the outside. Instead, it was to create their own lockbox with a subtle flaw built into it, one that was invisible from the outside. Each time that compromised lockbox participated in a joint cryptographic calculation with another validator, it would quietly extract a small fragment of that validator's key share. On its own, each leak was insignificant. But over time, and across enough validators, those fragments allowed the attacker to reproduce the whole private key and take control of the vault.

As explained earlier, a validator creates their lockbox by selecting two large prime numbers and multiplying them together. The biprime is large, and that is what keeps the lockbox secure. However, the attacker did something different: instead of using two large primes, they used several small primes. The result is known as a multi-prime modulus.

The product of the primes (lockbox) still comes out to the same size relative to normal, so from the outside it looks completely fine. But splitting the lockbox size across several primes instead of two means each individual prime is smaller than normal. That dilution is what makes the lockbox unsound on the inside while looking unchanged on the outside, and that’s what led to the leak of key shares.

How a "failed" signature actually leaks a share

Each time the attacker participated in a signing exchange with another validator, their defective lockbox caused a tiny fragment of that validator's key share to filter through. Far too small to be useful in isolation, but repeated round after round with multiple validators, those fragments accumulate and provide all information necessary to take control of a vault.

When a computation between validators passes through a genuine biprime modulus, the result can only be "read" in two ways: once through the lens of the first prime, once through the lens of the second. The protocol is designed around exactly those two readings, and neither one reveals anything about the secret. A multi-prime modulus built from several relatively small primes adds more lenses. The protocol doesn't account for it, doesn't hide it, and doesn't know it's there. But the attacker does, because they chose those several primes themselves. Every computation that passes through their modulus produces a result that can be read through that extra lens, and reveal a fragment of the other validator's secret key.

To collect enough fragments, the attacker deliberately caused signing rounds to fail, over and over again, while collecting small fragments of other validators key shares each time. After 864 repetitions over two and a half days, the attacker had accumulated enough material to sign transactions unilaterally, bypassing TSS.

Why This got Through, and Why it Didn't Get Worse

Why nobody caught it at the time

A failed signing round is not unusual on a network of this size. Validators regularly go offline, miss timing windows, or encounter software issues for entirely legitimate reasons. These failures result in minor slashes to discourage the behavior, however the attacker simply absorbed those penalties.

There's no quick, cheap way to look at a large number and tell how many primes were multiplied together to build it. That's not a gap specific to THORChain, it's a basic fact of number theory, and the same fact that makes this kind of cryptography useful in the first place. If counting a number's prime factors were easy, breaking the encryption that secures the internet would be too.

In practice, a local verification check can confirm a number is the right size and isn't divisible by small, easily guessable primes. It cannot confirm if a number is the product of two primes or three, or four, etc., only the person who built it knows that for certain. THORChain ran the tests it was capable of running, and the attacker's modulus passed every one of them. A later version of the library, which, by the incident time was not adopted by THORChain, does enforce a cryptographic verification of a well-formedness of the parameters. This enhancement however, wasn’t flagged as a critical update since literature-known attacks were not applicable to the version used by THORChain. As explained below, a successful attack required exploiting three weaknesses in a row. The community and THORSec, however, since no confirmed attack scenario was known on the current GG20 version, were focused on shifting away from the GG20 protocol into one with a smaller attack surface (namely, the DKLS) rather than keep auditing the existing one.

Why didn't it spread further

Two separate factors limited the damage here.

The first is mathematical. The flaw lives specifically in ECDSA, the signature scheme GG20 uses, and is tied to the Paillier lockbox mechanism described above. Chains using a different signature scheme, EdDSA, including Solana, are not susceptible to this attack.

The second is structural. THORChain spreads liquidity across several vaults, therefore extracting more funds would have meant repeating the same attack on another vault. That requires running another validator node, with real bonded capital at stake, hundreds of thousands of dollars per node. Attacking multiple vaults at once would have been costly and logistically demanding. The working theory is the attacker didn't have the capital to do it.

Why did the solvency checker not halt it in time

THORChain's automatic defenses, the solvency checker and automatic transaction halts, didn’t stop this attack. Normally, those systems are the network's primary line of defense. They watch for suspicious fund movement and pause it before damage occurs.

It didn't happen here, because the attack was already over by the time funds actually moved. The compromise happened upstream, during 864 quiet, unremarkable signing failures, long before any crypto moved. The attacker acquired the entire private key and moved all the assets in one transaction, before any halt could have effect.

Why this is Sophisticated, and Different from a Typical Hack

A few things separate this exploit from the attacks DeFi users are used to reading about. It's worth being explicit about what this wasn't: not a smart contract bug, not a bridge vulnerability, not a compromised multisig signer, and not an operator making a careless mistake. Those failure modes account for the vast majority of losses across the industry. This was something entirely different: a cryptographic attack targeting the mathematics that allow validators to sign transactions together.

The attack relied on three separate weaknesses in the cryptographic library THORChain inherited from Binance, none of them alarming on their own. The first let an attacker submit a malformed key during vault setup that looked legitimate but wasn't. The second was a gap in how the protocol checked that signing exchanges were honest, a gap that let the attacker shape their submissions in exactly the way needed to exploit the first weakness. The third was a value meant to mask sensitive information during signing that wasn't random enough to actually hide it, leaking a sliver of secret data in every single round.

None of the three flaws were dangerous in isolation. Even the malformed-key weakness, the only piece that had ever been publicly discussed before, was considered low-risk on its own because it only worked occasionally and would have been slow and noticeable. What nobody had ever identified, anywhere, was that the other two flaws could be layered on top of it, turning that slow, unreliable leak into a fast and reliable one.

That combination, not any single bug, is what made this a zero-day: it existed in no advisory, no audit, and no public research before the attacker found it. Exploiting it required genuine cryptographic expertise. Seeing the path meant understanding how Paillier moduli, biprimes, range proofs, and the masking assumptions behind multi-party signing interact at a mathematical level, recognising that three separately harmless defects could reinforce one another, and then orchestrating that interaction across hundreds of individually unremarkable protocol messages.

For readers who want the full technical detail, the appendix offers a more precise breakdown of how the three weaknesses combined to enable the attack.

THORChain's security team attempted to reproduce the exploit using the most advanced AI models available, with the compromised key shares already in hand and knowing exactly where to look. It still took two advanced cryptographers working around the clock alongside those models before a working proof of concept could be produced. In other words, it wasn't something a simple prompt could create.

Security has always been taken seriously within THORChain. The protocol has undergone extensive auditing throughout its history. None identified this attack path. It’s not necessarily surprising as audits are designed to identify known cases of vulnerabilities within a defined scope. Hypothesising on cryptographic computations and then proving it was exploitable, is not what a standard audit does.

The attack was also patient and deliberately quiet. Every individual action taken by the attacker appeared indistinguishable from normal network activity. Churning in as a validator looked ordinary. Failing a signing round looked ordinary. Absorbing a small penalty looked ordinary. The only thing that reveals the pattern is the aggregate: a single validator responsible for a wildly disproportionate share of signing failures over a short period of time.

What Changes Now?

In the short term, every validator upgraded to the patched release (Version 3.19.1). The network ran a coordinated verification process across all vaults before normal signing and fund movements resumed.

In the medium term, THORChain is going to move away from GG20 entirely and adopt alternative signing schemes, such as DKLS and/or Schnorr-based approaches, that are mathematically simpler and do not rely on Paillier cryptography. This was already part of the road map before the hack, because a smaller and simpler attack surface is inherently easier to secure.

Other changes under consideration include a minimum age requirement for wallets before they can operate a validator node, giving the community more time to identify and patch vulnerabilities before a new validator can take advantage of them. Another proposal is gradual exposure, where new validators begin securing smaller vaults and progressively earn access to larger ones over time. A dual-scheme architecture is also being explored, where each vault would have a 2-of-2 multisig and each key would be secured by a different cryptography, requiring an attacker to break two independent signature systems rather than one.

Monitoring is also being strengthened. The network is adding active monitoring of key-sign failures at the validator level. In this case, a single validator was responsible for a disproportionately large share of signing failures, a signal that would have been a valuable early warning indicator had it been tracked at the time.

The bug bounty program will be reassessed and redesigned with a model better suited to the current landscape. The program was paused on March 31, 2026 for one year. The reason for suspending it was a surge in low-quality, AI-generated submissions that had become an unsustainable drain on the security team's time, time that is better spent implementing the structural improvements outlined above.

THORChain, its node operators, contributors, and broader community would like to thank everyone for their patience, support, and assistance throughout the recovery effort. The past weeks have been challenging, but they have also demonstrated the resilience and coordination of a community committed to restoring the network safely and correctly.

Appendix - Technical explanation of the three weaknesses in the chain

The attack did not turn on a single flaw. It worked by combining three separate weaknesses in the threshold-signature library THORChain inherited from Binance: one in key generation, two in the message exchange that produces each signature; individually, none of the three is alarming.

The first is in key generation. Whenever a vault is created, every participant publishes a Paillier public key: a large modulus that underpins the encrypted arithmetic the signing protocol runs on, which is supposed to be the product of two large primes. The library never actually verified that; it only screened out a handful of tiny factors. A malicious participant could therefore publish a deliberately malformed key, secretly built from many small prime factors, and have every honest party accept it as legitimate. This screening was believed to be sufficient for blocking disastrous cryptographic attacks.

The second is in the signing protocol's range proofs. In each round, a party must prove that the encrypted value it is contributing is well-formed and within bounds, without revealing the value itself. The check meant to enforce this verified two halves of the proof in isolation and never tied them together, which let a malicious party satisfy the proof while encrypting a value of its own choosing, in particular, one crafted to interact with the malformed key from the first weakness.

The third is in the companion proof on the other side of that same exchange. To attest that it had behaved honestly, each party masks a sensitive intermediate value with a random blinding term. That term was drawn from a range far too small to actually hide what it covered, so a sliver of the value it was meant to conceal leaked in every single signing session.

All three weaknesses the attacker exploited had already been fixed in Binance's upstream tss-lib (two in the v2.0.0 hardening release of August 2023, the third in v3.0.0 in 2024) but they were addressed as isolated, individually-minor issues, and no published analysis ever connected them or described their combination as a practical route to a private key.

THORChain's deployed fork (v0.1.6) predated all three fixes, and when our security team reviewed the same weaknesses earlier it reached the conclusion Binance's own maintainers had reached implicitly: in isolation, none of them opened an exploitable path, and none justified an emergency upgrade. Add to that the fact that touching a cryptographic code requires a huge resource allocation and focus, rather than blindly relying on upstream updates. In late 2025 the team re-checked known vulnerabilities (BitForge and TSSHOCK) and found that these attacks are not applicable to the production version library used by THORChain.

Only one of the three weaknesses corresponds to anything in public literature. The Paillier-modulus condition, a key whose modulus secretly carries many small prime factors, is the same class of weakness documented in 2023 as BitForge and TSSHOCK. On its own, that condition is only weakly exploitable: it leaks a victim's secret share one small prime at a time, and only probabilistically.In each signing session, the known attack alone offered only a probabilistic chance of extracting useful information, roughly one in 131,000 per session, determined by the size of the small prime factors hidden inside the malformed modulus. At those odds, a real extraction would have required millions of attempts and would have been slow. That is exactly why the known vulnerability was considered low-risk on its own.

That is why it was judged low-risk for THORChain. What had never been described anywhere was that two other, unremarked-on flaws in the same library (a range proof that failed to bind a commitment to the ciphertext it was meant to certify, and a blinding value sampled far too small to hide what it masked) could be layered on top of that condition to remove the probability entirely.

Combined, they convert a slow statistical gamble into a deterministic leak: a single malicious signer recovers an honest party's full secret share in a fixed, small number of sessions, and the entire vault key after repeating it across the committee. That exploit chain was the zero-day. It existed nowhere in the public record, in no advisory, no CVE, and no prior audit of the library, and the attacker was the first to assemble it.

Glossary

TSS (Threshold Signature Scheme): a method where a group of validators jointly produce a signature without any single party ever holding the full private key.

GG20: a Threshold Signature Scheme protocol introduced by cryptographers Gennaro and Goldfeder in 2020, designed for ECDSA-based multi-party signing. THORChain used a fork of Binance's implementation of this protocol to secure its vaults.

Paillier cryptosystem: an encryption method that allows certain calculations to be performed on encrypted numbers without decrypting them first, used here to let validators compute jointly without revealing their individual secrets.

Biprime: a number formed by multiplying two large prime numbers together. Security in this context depends on biprimes being extremely difficult to factor back into their original primes.

Multi-prime modulus: a number built from three or more primes multiplied together rather than two. Structurally weaker and easier to break than a true biprime, despite looking superficially similar.

MTA round: a specific exchange step in the TSS signing process where validators perform calculations using each other's encrypted secrets.

Key-sign: the multi-party process validators go through to produce a signature authorising a transaction.

Validator / Node: a participant running THORChain software and contributing to securing and signing transactions on the network.

Vault (Asgard vault): a pool of funds secured collectively by a rotating set of validators using TSS.

Churn: the process by which validators join or leave the active signing set.

Zero-day: a vulnerability unknown to defenders until the moment it's exploited, with zero days to prepare a fix.