Vultisig developers are working on a fix for a message-signing bug that causes the wallet’s manual personal_sign function to sign a raw cryptographic digest instead of applying the Ethereum message-signing protection users would normally expect from that method.
The issue was publicly reported on October 8 in Vultisig’s Windows repository as issue #5137. The reporter reproduced the behavior in extension version 1.0.75 and said version 1.0.74 was affected as well.
The bug sits specifically inside Vault Settings → Advanced → Sign custom message. When a user selects personal_sign and enters ordinary text, the resulting signature reportedly validates against the raw keccak256 hash of that message rather than the prefixed message required by Ethereum’s standard signing convention.
The distinction becomes more important when the input begins with 0x. According to the report, Vultisig interprets valid hex input as bytes. A 32-byte hex value pasted into the form can therefore become the exact digest handed to the signing operation.
There is no evidence that the bug has been exploited, no reported theft tied to it and no demonstrated malicious dApp route. The normal dApp personal_sign path reportedly already handles Ethereum message signing correctly. The exposed behavior is in the manual Advanced signing interface, meaning a practical attack would currently appear to require convincing the user to enter attacker-selected data manually.
Vultisig Opened a Same-Day Fix
The repository moved quickly after the disclosure.
Pull request #5142, titled “sign custom personal_sign messages with the EIP-191 prefix,” was opened the same day and explicitly references issue #5137. The PR remains open and unmerged, so it should not yet be treated as a released fix.
The proposed patch confirms the core diagnosis in the original report.
According to the PR description, the Advanced settings form placed the bare message into Vultisig’s keysign payload. Devices participating in the signing process then hashed that payload directly and did not add an Ethereum message prefix themselves.
Vultisig’s dApp popup already behaves differently. It wraps personal_sign content in the expected Ethereum envelope before constructing the payload, which explains why the same signing method could behave correctly through a dApp but differently through the manual settings screen.
The proposed fix makes the manual form use the same wrapping logic.
Tests added with the PR recover the expected Ethereum address using standard message verification after the patch. The developer also documented a manual test in which the patched extension correctly verified an ordinary personal_sign message, while an unpatched build recovered the vault address only when the verifier used the raw message hash.
Why EIP-191 Exists in the First Place
Ethereum deliberately distinguishes a signed human-readable message from a signature intended for some other purpose.
The EIP-191 signed-data standard introduces a recognizable prefix before the message is hashed and signed. For the convention used by personal_sign, that includes the familiar Ethereum Signed Message marker and the message length.
This is a form of domain separation.
Instead of giving an application a signature over an arbitrary digest, the wallet produces a signature over a hash that clearly belongs to the Ethereum message-signing domain.
That separation matters because the same elliptic-curve signing primitive can otherwise be used in very different contexts. A signature is not inherently aware whether the digest underneath it represented a login challenge, a transaction, an authorization, a structured order or a harmless sentence.
The prefix makes those contexts harder to confuse.
Wallet security increasingly depends on getting these surrounding signing semantics right. A recent bitcoinj wallet vulnerability similarly demonstrated how infrastructure around a mature cryptographic system can become the real security boundary even when the underlying signatures and blockchain remain intact.
A 32-Byte Input Is the More Interesting Edge Case
The most consequential part of the Vultisig report is therefore not that ordinary text produces a signature other software cannot verify as standard personal_sign.
It is that a valid 32-byte hexadecimal input can apparently be treated as the digest itself.
Conceptually, that turns the Advanced interface into something closer to a generic raw-digest signer while presenting the operation under the familiar personal_sign label.
That does not automatically produce an exploit.
An attacker would still need to know a useful digest from another signing domain and persuade the victim to paste that exact value into Vultisig’s Advanced interface and approve the signature. The resulting signature would then need to satisfy whatever verification rules exist in the target protocol.
No public proof of concept has demonstrated that chain end to end.
But it creates a useful security question: could a digest corresponding to a transaction, structured permit, authorization or authentication request be presented to a user as an innocuous “message,” signed through the affected path and then reused elsewhere?
That is precisely the class of ambiguity message-domain separation is designed to reduce.
The Risk Is What the Key Is Asked to Sign
This is also why protecting private keys is only one part of wallet security.
A key can remain perfectly secret while software feeds it the wrong thing to sign.
The distinction appeared clearly in the recent Safe multisig attack involving a third-party Aave module. The important security question was not simply whether the underlying multisig cryptography worked, but whether trusted components could cause legitimate wallets to authorize an unintended outcome.
Vultisig’s issue is much narrower and there is no evidence of comparable financial damage. But the underlying security principle is similar: custody software has to protect the path between what the user believes they are approving and the bytes actually submitted to the signing primitive.
A screen labelled personal_sign creates a reasonable expectation that the standard personal_sign domain separation is being applied.
If the operation instead exposes raw-digest signing, the interface is providing a stronger and potentially more dangerous capability than the label suggests.
The Fix PR Points to iOS and Android as Well
The Windows extension may not be the only implementation requiring attention.
The author of PR #5142 says the corresponding manual custom-message flows on Vultisig’s iOS and Android applications appear to use the same bare-message approach.
The PR notes that the iOS SettingsCustomMessageView and Android SignMessageFormViewModel appear to have the same bug, although separate issues had not yet been filed when the patch was written.
That finding is not the same as demonstrating an exploitable vulnerability on every platform. The PR also says Secure Vault co-signing with iOS and Android had not been manually tested as part of the Windows fix.
Still, it broadens the remediation question beyond a single browser extension release.
The good news is that the underlying co-signer behavior is already compatible with the proposed fix because the dApp flow has apparently been sending EIP-191-wrapped payloads through the same signing infrastructure successfully.
A Signing Bug Does Not Need a Key Leak to Matter
The Vultisig report is currently a preventive security story, not an incident response story.
There are no demonstrated victims, stolen assets or malicious websites exploiting issue #5137. The affected functionality is also buried inside an Advanced manual signing flow rather than automatically exposed to ordinary dApps.
Those constraints substantially reduce the immediate attack surface.
But wallet incidents repeatedly show why user intent needs to be treated as a security property. Malware and fake wallet software often succeed not by defeating cryptography but by manipulating what users install, enter or approve.
A raw-digest signer can create the same category of problem at a lower level: the signature may be cryptographically valid while representing something different from what the user believed was being signed.
The most important next milestone is therefore a patched release, not merely the existence of PR #5142.
Vultisig will also need to determine whether the same manual signing behavior should be corrected on iOS and Android, ensure regression tests cover 32-byte hexadecimal inputs and verify that no other interface exposes raw digest signing under a safer-looking message-signing method.
Until then, the confirmed finding is narrow but technically meaningful: released Vultisig extension versions can use the Advanced personal_sign path to sign a raw message digest, while the standard dApp path applies the expected Ethereum envelope. A fix now exists in review, but it has not yet reached users.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape.