A newly disclosed Vultisig browser-extension vulnerability can cause an Ethereum signature to cover a different message from the one displayed to the user for approval, creating a “what you see is not what you sign” failure at one of a crypto wallet’s most important security boundaries.
The issue was opened in Vultisig’s public GitHub repository at 08:24 UTC on October 5 and marked high priority. It affects the extension’s implementation of Ethereum’s personal_sign method, which decentralized applications can use to request cryptographic signatures from a connected wallet.
The report does not identify any real-world exploitation, stolen funds or affected users.
Instead, the proof of concept demonstrates a mismatch between what Vultisig shows in its approval popup and the exact bytes the wallet ultimately signs.
The vulnerability is particularly relevant to Vultisig Fast Vault users because the second signing party is an automated Vultisig server rather than another person reviewing the message on a separate device. In that configuration, the extension popup becomes the user’s main opportunity to verify what is being authorized.
The Popup Trusts a Message Length Supplied by the Web Page
The flaw comes from how Vultisig constructs Ethereum’s EIP-191 message prefix.
Under personal_sign, Ethereum does not simply sign the text shown to a user. Before hashing, the wallet creates a payload beginning with \x19Ethereum Signed Message:\n, followed by the message length and then the message itself.
Vultisig’s current implementation receives both the message and a separate field called bytesCount.
Normally, the extension’s higher-level Ethereum provider calculates that value from the real message length. The security problem is that the lower-level popup accepts the value supplied through the page-facing request without independently recalculating it from the message it displays.
The public Vultisig vulnerability report demonstrates the issue with a deliberately constructed request.
The page supplies the displayed message 2hello world! but sets bytesCount to 1.
The popup shows the user:
2hello world!
But Vultisig constructs the bytes to be signed as:
\x19Ethereum Signed Message:\n12hello world!
That byte sequence is the valid EIP-191 representation of the 12-byte message:
hello world!
The result is a cryptographically valid signature for hello world!, even though the user approved a popup displaying 2hello world!.
A Connected dApp Can Reach the Vulnerable Signing Path
Reviewing the extension’s communication code helps explain why the issue matters.
Vultisig injects an Ethereum-compatible provider into websites and routes signing requests through a browser bridge to the extension background process. The background layer does enforce account and chain authorization, meaning an arbitrary unconnected webpage cannot simply obtain a signature from a user’s vault.
A dApp that has already been authorized for the relevant account and chain, however, can make signing requests through that path.
The popup’s input type currently accepts bytesCount as a number alongside the message. Runtime code then uses that separate field when constructing the EIP-191 payload instead of deriving the length again from the actual bytes being displayed.
That makes the issue different from a purely visual rendering problem. The signed cryptographic object itself changes.
Dave Finances reported another Vultisig extension trust-boundary bug only a day earlier, in which an unconnected website could persist attacker-controlled Keplr chain information that later affected other websites. The two bugs involve different features, but both concern assumptions made between web-page-controlled data and trusted wallet state.
The Vulnerable Logic Dates Back to October 2025
The relevant bytesCount handling appears to have entered Vultisig’s codebase in an October 22, 2025 change intended to fix invalid Ethereum personal signatures.
That change moved message-length information into the signing flow so the correct EIP-191 prefix could be constructed for text and hexadecimal messages.
The implementation solved one signing problem but created another assumption: the popup trusted the separately supplied length rather than computing it from the exact message bytes it was preparing to sign.
The vulnerable logic remains in the repository’s current main branch.
Vultisig’s Chrome Web Store listing currently shows extension version 0.2.27, updated September 28, with roughly 3,000 users. Vultisig has not published a formal list of affected extension versions, so the public evidence does not justify claiming that every historical release is vulnerable.
More importantly for users, no patched Chrome extension version has yet been announced.
A Fix Has Already Been Written but Has Not Yet Been Merged
Vultisig moved quickly after the October 5 disclosure.
A follow-up pull request removes bytesCount from the popup input entirely. Under the proposed design, the popup itself decodes the displayed message, calculates the true byte length and builds the EIP-191 prefix from those same bytes.
That collapses two previously separate sources of truth into one.
The patch also adds regression tests covering ordinary text, hexadecimal messages, multibyte UTF-8 characters and messages beginning with digits like the proof-of-concept example.
The developer says a manual test using a Fast Vault confirmed that the patched build displays 2hello world! and produces a signature that verifies against that exact message.
At the latest check, however, the pull request remained open and had not been merged into the main branch.
Fast Vault Makes the Display Boundary Particularly Important
Vultisig uses threshold-signature technology rather than storing one conventional private key inside the browser.
Its Fast Vault pairs a share held on the user’s device with another share controlled by Vultisig’s Vultiserver infrastructure. The server acts as an automatic co-signer when configured conditions are satisfied, giving the user a single-device experience while retaining a two-party signing model.
That architecture protects against several classes of private-key compromise, but it does not independently solve a misleading signing prompt.
If the user-facing device constructs the wrong payload after showing the user a different message, threshold cryptography can faithfully sign the wrong payload.
The server co-signer does not provide a second human looking at an independent representation of the message.
This is the same broader security lesson seen in the recent Safe module exploit involving Aave positions: strong cryptography can work exactly as intended while a surrounding authorization layer feeds it the wrong instruction.
This Does Not Automatically Let a Website Sign an Ethereum Transaction
The potential impact needs an important limit.
A personal_sign signature is not itself a normal Ethereum transaction. EIP-191 deliberately prefixes signed messages in a way designed to prevent them from being interpreted as raw Ethereum transactions.
The vulnerability therefore does not demonstrate that a malicious dApp can simply make Vultisig transfer ETH or tokens by disguising a transaction as harmless text.
The downstream risk depends on what another application accepts the signature as authorization for.
Message signatures are widely used for wallet authentication, account ownership proofs, session creation, off-chain instructions and application-specific authorizations. Some trading or DeFi systems also use signed off-chain messages as inputs to later actions.
If a relying service considers the hidden underlying message authoritative, a valid signature over that message may have consequences even though the user saw different text.
Exactly how useful the digit-length ambiguity would be against real authentication or financial protocols now becomes the key exploitation question.
The Dangerous Part Is Breaking the User’s Final Check
Wallet security is often discussed as if the private key were the whole problem.
That misses what actually happens when people use self-custody.
Users rarely inspect raw cryptographic payloads. They depend on wallet software to translate a request into something understandable and then ask, effectively: “Do you approve this?”
That confirmation screen is a security control.
If the screen displays one object while the cryptographic system signs another, the user’s approval is no longer meaningfully attached to the resulting signature.
The problem resembles other crypto failures where the most sophisticated security component was not the one that broke. In the FomoPeek mobile security incident, researchers said malicious software attacked the operating environment surrounding wallets rather than defeating blockchain cryptography itself.
Vultisig’s case is smaller and there is no reported theft, but the principle is similar: the security model can fail one layer away from the keys.
The Second Vultisig Extension Disclosure in Two Days Deserves Attention
The timing makes the issue more notable.
October 4 brought the disclosure that Vultisig’s Keplr-compatible chain-suggestion system could allow unconnected websites to persist false chain metadata without proper approval.
October 5 brought a separate issue at the Ethereum message-signing boundary.
There is no evidence that the vulnerabilities share a root cause or that attackers have exploited either one.
But both emerged in the browser extension, where Vultisig is translating untrusted dApp requests into actions performed by a high-value self-custody wallet.
That makes the extension’s trust boundaries especially important to audit.
Vultisig’s open-source development model is helping here: the bugs are visible, reproducible and fixes can be inspected publicly. The other side of that transparency is that a disclosed flaw remains useful information to attackers until the patch actually reaches users.
The Fix Matters More Than Whether Anyone Has Exploited It Yet
There is currently no evidence of stolen assets, malicious dApps using the mismatch or a campaign targeting Vultisig users.
That should keep the story in proportion.
But absence of observed exploitation does not make the signing mismatch trivial.
The wallet’s final confirmation interface is supposed to bind human intent to a cryptographic signature. The proof of concept demonstrates that those two things can diverge.
That is particularly uncomfortable in self-custody, where a bad authorization may be irreversible and there may be no exchange operator able to cancel the action or reimburse the user. Dave Finances previously examined that problem through the difficulty of measuring and recovering from self-custody losses.
The good news is that Vultisig’s proposed remediation is conceptually simple: never trust the requesting page to tell the wallet how long the message is. Calculate the length from the exact bytes the wallet displays and signs.
The next milestone is therefore straightforward.
Vultisig needs to merge the patch, ship it in a browser-extension release, identify which released versions are affected and make clear whether users need to take any action.
Until then, the issue remains a high-priority example of a deceptively small implementation detail breaking one of the most important promises a wallet makes to its user: that the thing on the approval screen is the thing their signature actually authorizes.
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.