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.
What the August changes demonstrate
The Android change (#5658) and iOS change (#5235) were both merged on Aug. 21, two months before public disclosure.
Their descriptions say the old code compared signing failures with the library’s success result without separately handling malicious-party ban errors. The signing routines could retry up to three times, while the user received a generic failure message.
That retry count does not establish how many messages would recover a key, or how many sessions an attacker would need.
The Android code changes and iOS changes recognize the DKLS signing library’s malicious-party error codes 100–109 during session setup, message processing, and signature completion.
Both map the flagged participant to a device identifier, carry a dedicated error past automatic retries, and display a localized warning against using that device again. On Android, the exception also bypasses relay recovery.
Together, those changes show that the apps distinguish a cryptographic verdict about a participant from an ordinary signing failure.
Retry behavior appropriate for a temporary failure can become dangerous when the library is telling the caller to stop interacting with a malicious signer.
The GitHub notes for iOS v1.45.71, dated Aug. 21, list #5235. The Android v1.0.118 release, dated August 25, lists #5658.
Wallet counts and audit scope need context
Vultisig’s vault descriptions distinguish who controls the signers. Fast Vault uses one user device with VultiServer holding the second share and co-signing. Secure Vault uses two or more user-held devices without VultiServer.
A provider-assisted wallet and a wallet spread across a user’s own devices can both use distributed signing, but their operational dependencies differ. Two participants in a signing exchange also need not mean the vault has only two shares in total.
The reviewed disclosure and application materials do not provide a full affected-version and vault-configuration matrix.
Vultisig’s security documentation says Trail of Bits audited the Silence Laboratories DKLS23 library in 2024. It says mobile and desktop application audit reports will be linked when published.
At disclosure, ChainSecurity said it had not reviewed Vultisig’s fixes or audited other parts of the protocol, so the fixes remained outside that assessment.
Useful remediation details would connect affected configurations to shipped versions and explain enforcement after both automatic and user-initiated restarts. A review covering those behaviors would address the application-level failure described here.
The protection holders are promised that enforcement depends on the application enforcing the library’s stop condition throughout signing, including when users start again after a failure.
Analysis,Featured,Hacks,Wallets,Bitcoin,BTC,ETH,ethereumBitcoin,BTC,ETH,ethereum#August #updates #block #critical #private #key #leak #crypto #wallet #Vultisig1793052169
