Vultisig's August Patch Fixed a Key Leak That Needed Only One Compromised Signer

A multisig wallet is supposed to make one stolen key survivable. That's the entire sales pitch. Vultisig just showed how thin that promise can get when the code enforcing it has a gap.

A flaw in the wallet's ECDSA signing flow let an already-compromised signer keep feeding malicious messages at the application until it leaked enough material to recover a private key. The fix landed in the August updates. One bad signer. That's all it took.

The Missing Abort

Here's how the exploit worked. Threshold ECDSA splits a key into shares, one per signer, and reassembles nothing. Each signature is a small ceremony where every node contributes a piece and nobody ever holds the whole thing. The math is solid. It's been solid for years.

But the math only protects you if each node enforces its own abort conditions. A signing node is supposed to check incoming requests and kill the session when something looks wrong. Malformed message, out-of-range value, duplicate nonce, whatever the spec says. Stop, don't sign, log it.

Vultisig's application was ignoring one of those stop conditions.

That's the whole bug. The vulnerability was hiding in plain sight, in the control flow around the cryptography rather than inside it. With that abort check missing, a hostile signer gets to choose the inputs across a long series of signing requests. It can nudge nonces into biased ranges without ever tripping an alarm. Each signature leaks a sliver of the honest party's share. Then you collect enough slivers and run lattice reduction on the results. No brute force. No broken elliptic curve. Just linear algebra against biased noise.

How much leakage does it take? At one to two bits of bias per signature, a few hundred carefully crafted requests is usually enough to reconstruct a 256-bit key. That's not a theoretical exercise. It's a well-documented attack path, and it's the reason nonce hygiene gets hammered into every crypto engineer's head from day one.

The cryptography held up fine. The code around it didn't.

Why This Bug Class Keeps Winning

Look at how threshold wallets get audited. Most of the review budget goes to the protocol math. Proving the secret sharing is sound, checking the MPC rounds, validating that no party learns another's share. Fair enough, that's the hard part.

The soft part is the state machine. What happens when a session gets resumed? What happens when a peer sends 400 messages instead of 4? What happens when the check that's supposed to fail open doesn't? Those questions don't fit neatly into a math proof, so they get less attention.

And that's backwards, because the state machine is where attackers live. Breaking 256-bit ECDSA is a nation-state research project. Finding a missing abort condition is a Tuesday.

So why does a single compromised signer still matter in a design built to tolerate exactly that? Because "tolerate" only holds when every honest participant enforces the protocol as written. The security model assumes the good nodes behave correctly. Strip out one stop condition and you've quietly changed the trust assumptions without changing the marketing copy.

How many other wallet apps are running signing loops with the same unchecked path? Nobody knows. That's the uncomfortable part. This class of flaw doesn't show up in a block explorer or a TVL dashboard. It shows up when someone finally looks.

Who loses here? Users who treated "multisig" as a finished answer rather than a configuration. Teams that shipped a signing flow without adversarial testing against their own spec. And every auditor who signed off on the math without walking the failure paths.

Who wins? Vultisig, honestly, if it treats this as a near miss rather than a closed ticket. The team caught it, patched it in August, and no funds are gone as far as anyone's said. That's the good ending. Plenty of these stories end with an empty contract and a post-mortem nobody wants to write.

The rest of the market wins too, if it pays attention. Every threshold wallet now has a concrete reason to go re-read its own abort logic.

The Takeaway

Multisig and MPC wallets get marketed as removing single points of failure. That's not quite true. They move the single point of failure from the key to the coordination layer, and the coordination layer is usually less scrutinized than the key.

The attack vector was straightforward: one compromised signer, many malicious ECDSA messages, one ignored stop condition. This could have been prevented with a test that feeds a signing session garbage and asserts that it dies. That's it. That's the whole defense. Assert the abort.

So if you're holding funds in a threshold wallet, ask the team one question. Show me the code path that rejects a bad signing request, and show me the test that proves it. If the answer is a link to a math audit and nothing else, move. Funds might be safu today. The stop condition is what keeps them that way tomorrow.