Vultisig updated its Android and iOS apps in August to stop automatically retrying multi-party signatures after the signing library flags a participant as malicious. The change, disclosed by ChainSecurity on October 21, addresses a flaw that could let an attacker who had compromised one signer gradually recover another participant’s key share by sending malicious messages and monitoring error responses.
The issue affected ECDSA signing and highlights a risk in multi-device wallets: security depends not only on splitting key material, but also on whether the app stops protocol interactions when the signing library signals that it should. Even when a failed signing attempt produces no usable transaction, its error responses may still reveal information.
Error responses could expose a protocol seed
Multi-party computation wallets distribute signing authority across key shares. During a normal signing session, participants work together to produce a standard blockchain signature without reconstructing the full private key. In a setup requiring two devices, an attacker controlling only one would generally still need the other device’s participation to sign.
The attack described by ChainSecurity assumes that one participant has already been compromised. An attacker could send multiple malicious signing messages to another participant and monitor whether it returns an error. Researchers said those responses could gradually reveal information about a reusable internal protocol seed. With continued exploitation, an attacker might recover the other participant’s key share and ultimately reconstruct the full private key.
The seed is a secret used internally by the protocol. The signing library assumed that, after a serious error, the calling application would stop further signing until the seed was rotated. Older app versions did not enforce that condition: they displayed a generic failure message and could continue retrying. The concern was therefore not whether one failed signature could be broadcast, but whether the app kept communicating with a participant the library had flagged.
August updates stop retries after malicious-participant errors
Maintainers merged the relevant Android and iOS code changes on August 21, about two months before the issue was publicly disclosed. The older code compared signing failures with successful results from the signing library but did not separately handle errors that ban a malicious participant. The signing flow could retry up to three times, while users received a generic failure message. That retry limit does not indicate how many messages would be needed to recover a key, nor does it establish how many sessions an attack would require.
The updated apps recognize DKLS signing-library malicious-participant error codes 100 through 109 at stages including session setup, message handling and signing completion. Both apps map the flagged participant to a device identifier, prevent the error from being swallowed by automatic retries and show a localized warning telling users not to continue using the device. The Android app also skips the relay recovery process.
The change distinguishes an ordinary signing failure from a cryptographic library’s determination that a participant is malicious. Retrying may help recover from a temporary problem, but continued interaction after the library has instructed the app to stop could increase information exposure.
The changes are documented in Android PR #5658 and iOS PR #5235. The release notes list August 21 for iOS v1.45.71 and August 25 for Android v1.0.118, with both releases including the fix.
Scope across vault configurations remains unclear
Vultisig describes two signing arrangements. In a Fast Vault, the user’s device holds one share and VultiServer holds another, with both participating in signing. In a Secure Vault, signing is distributed across two or more devices controlled by the user, without relying on VultiServer. Both use distributed signing, but their operational dependencies differ; two participants in a particular signing session do not necessarily mean the entire vault has only two shares.
The published research and app materials do not provide a complete mapping of affected versions to vault configurations. As a result, users cannot determine from the available information exactly which configurations were affected or how the updates cover different historical versions.
Vultisig’s security documentation says Trail of Bits audited Silence Laboratories’ DKLS23 library in 2024 and that audit reports for the mobile and desktop apps would be provided after publication. When ChainSecurity disclosed the issue, it said it had not reviewed Vultisig’s fix or audited other parts of the protocol. Those application-level changes were therefore outside its assessment.
Further clarification is needed on which released versions and vault configurations were affected, and whether the stop condition applies both to automatic retries and to users manually restarting a signing session. The issue centers on whether the application consistently enforces the library’s instruction to halt interactions throughout the signing process.