August updates block critical private key leak in crypto wallet Vultisig
An already-compromised signer could recover the key through many malicious ECDSA messages when the application ignored a critical stop condition. Read the full story on CryptoSlateUnderstand the crypto stories that matter and what to watch next. Get The Catalyst in your inbox
Vultisig, a crypto wallet that uses shared signing, mishandled a critical stop signal in its ECDSA signing implementation, as security researchers at ChainSecurity found.
The researchers’ Oct. 21 disclosure describes how continuing after the error could let one already-compromised signer recover the full private key.
Both the Android and iOS maintainers described code that retried after the library identified a malicious participant, then added handling to stop those retries and warn the user. The changes appear in subsequent repository release notes.
Requiring several devices offers protection only if the software preserves that requirement when one participant starts misbehaving.
A multi-party computation wallet (MPC wallet) distributes signing authority among key shares. Enough shares cooperate to produce a standard blockchain signature without assembling the full private key during normal operation.
In a two-device arrangement requiring both participants, compromising one should leave the attacker dependent on the other device’s approval.
The disclosed flaw involved ECDSA signing and required that initial compromise. An attacker could then send many malicious signing messages and observe whether the other signer returned an error.
Those responses revealed bits of a reusable internal protocol seed, eventually enabling recovery of the other share and the full key, according to ChainSecurity.
That seed is an internal setup secret, and the library assumed further signing would stop after the critical error until the seed was rotated. The application displayed a generic error and did not enforce that response.
The security consequence is that a failed signing attempt can matter even when it produces no usable transaction signature.
If continuing the exchange reveals more secret information, rejecting the transaction alone does not preserve the promised separation between signers. The application must respond to the protocol failure itself.