A newly opened security issue in Vultisig’s browser-extension code is raising a broader question for multi-chain wallets: when a user approves a seemingly harmless “sign message” request, can the resulting signature also be valid for an actual blockchain transaction?
According to an open issue in Vultisig’s official GitHub repository, the answer may be yes for several signing flows involving Solana, Polkadot and the XRP Ledger.
The report, opened on October 5 and categorized as a high-priority extension bug in its metadata, says Vultisig can sign raw bytes supplied by a connected webpage without sufficient separation between ordinary messages and transaction data.
No theft, wallet drain or exploitation in the wild has been reported. The issue describes a potential signing-confusion vulnerability demonstrated with test accounts, and the attack model still requires a user to approve a signing request.
The concern is what that approval actually authorizes.
Solana, Polkadot and XRPL Share the Same Underlying Problem
The issue describes three technically different paths that arrive at the same security problem: bytes presented to the user as a “message” may be usable in a transaction-signing context.
On Polkadot, Vultisig’s signRaw flow allegedly signs the webpage-supplied data directly. The report contrasts this with the convention used by polkadot-js, where raw messages are wrapped with <Bytes>...</Bytes> before signing.
That wrapper may look trivial, but cryptographically it changes what is signed. A signature over the wrapped message cannot simply be reused as a signature over the unwrapped transaction payload.
Without that separation, the report says a webpage could provide data formatted like a Polkadot extrinsic signing payload while the wallet treats the request as ordinary message signing.
The Solana case is conceptually similar. Solana transaction signatures cover the serialized transaction message itself. Vultisig’s reported sign_message path signs raw bytes, creating the possibility that transaction-message bytes could be passed through the message-signing route and receive a signature usable for the transaction.
There is an important limitation. A follow-up test pull request notes that Vultisig’s normal Solana provider path first interprets input as UTF-8, which can corrupt arbitrary serialized transaction bytes and make that particular route harder to exploit. The original issue argues that protections must nevertheless exist deeper in the popup and signing logic because page-controlled requests can reach those components through other paths.
XRPL has its own version of the problem. XRP Ledger transactions use specific signing prefixes and SHA-512Half hashing. The report says Vultisig’s hexadecimal message flow can hash arbitrary supplied bytes in a way that allows a transaction signing payload to be presented through a generic message-signing request.
A Follow-Up PR Reproduces the Problem but Does Not Fix It
The same contributor subsequently opened Vultisig pull request #5121 with tests covering Solana, XRPL and Polkadot.
The PR is unusually explicit about its purpose: the tests are designed to demonstrate the signing behavior, and several are expected to fail until a real fix is implemented. It states that the PR “does not fix” the vulnerability.
For Solana, the test constructs transaction-message-shaped data and expects Vultisig eventually to reject it rather than return a message signature.
For XRPL, the test sends data beginning with the ledger’s single-signing transaction prefix and expects rejection.
For Polkadot, the test expects raw data to be wrapped before it reaches the signing flow.
As of the latest review, both the original issue and the testing PR remain open. That means there is currently no merged patch in the repository resolving the three paths described in the report.
The finding applies specifically to extension signing logic. It does not claim that Vultisig’s underlying threshold-signature cryptography has been broken, that vault shares can be extracted or that attackers can remotely take over wallets without a signing interaction.
That distinction matters for a product built around multi-party signing. Vultisig describes itself as a multi-chain threshold-signature wallet supporting more than 30 networks, where signing authority is distributed rather than held in a conventional single private key.
TON and Cardano Raise a Different Kind of Signing Risk
The issue also identifies concerns involving TON and Cardano, although those findings are somewhat different.
For TON Connect proofs, the report says the approval interface can display an opaque hash while relying on a domain derived from a webpage-supplied manifest URL. The proposed change is therefore partly about showing users the real origin and readable signing context.
For Cardano, the issue says signTx currently routes a transaction-body hash through a generic message-signing popup. The requested improvement is a decoded transaction view so the user can understand what is actually being authorized.
Neither case is presented in issue #5118 as the same straightforward transaction-signature-reuse path described for Solana, Polkadot and XRPL.
They instead expose a related weakness: a cryptographic signing system can technically do exactly what software asks while the human approving the request still has little idea what those bytes represent.
The Real Security Boundary Is the Screen the User Sees
This matters well beyond Vultisig.
Crypto wallet security is usually discussed in terms of seed phrases, private keys, firmware vulnerabilities and malware. The Coldcard self-custody incident, for example, showed how implementation weaknesses can undermine assets even when users believe their keys are isolated.
But transaction authorization creates another attack surface entirely.
A wallet can protect the key perfectly and still produce a dangerous signature if it asks the user the wrong question.
That is why the distinction between “sign message” and “sign transaction” has become so important in wallet interfaces. Users have been trained to treat a transaction approval as serious because it may move funds, while message signing often feels closer to logging into a website or proving wallet ownership.
If the cryptography underneath does not enforce the same distinction, the safety difference may exist only in the interface.
This connects directly to the broader security-versus-usability debate around crypto wallets. Strong key protection is valuable, but it cannot compensate for an approval screen that fails to communicate what the signature can actually authorize.
Domain Separation Sounds Technical, but It Solves a Human Problem
The central concept here is domain separation.
In simple terms, a wallet should make signatures created for one purpose cryptographically unusable for another purpose.
A login signature should look different at the cryptographic level from a transaction signature. A governance vote should differ from a payment authorization. A proof of wallet ownership should not accidentally double as permission to move assets.
Without those boundaries, software is relying too heavily on labels such as “message” and “transaction.” Labels protect humans. They do not protect signatures.
That becomes even more important as self-custodial blockchain applications expand beyond simple asset storage into payments, authentication, DeFi, identity and application logins. One wallet may increasingly sign dozens of different types of data across multiple protocols.
The more purposes one signing key serves, the more dangerous ambiguous signing formats become.
This Could Become an Industry-Wide Wallet Audit Question
The most interesting implication of the Vultisig report may therefore be outside Vultisig itself.
Wallet developers routinely expose APIs named signMessage, signRaw, signData and signTransaction. Developers and users naturally assume those methods represent different levels of risk.
But that assumption only holds if the underlying protocol or wallet implementation guarantees the signatures cannot cross those boundaries.
For chains where arbitrary bytes and transaction payloads use the same signing primitive, wallet software may need to provide the missing separation itself.
That makes the obvious next step an industry-wide review of message-signing APIs, particularly across multi-chain browser extensions that normalize very different blockchain signing models behind one interface.
Vultisig’s proposed fixes are relatively straightforward in concept: wrap Polkadot messages, reject Solana transaction-shaped payloads in message flows, reject XRPL transaction signing prefixes, and make TON and Cardano approvals more understandable.
The larger issue is harder.
Wallets increasingly ask users to approve cryptographic objects they cannot realistically decode themselves. If a message-signing popup says “message,” users have to trust that the wallet has made it impossible for that signature to mean “transaction.”
Issue #5118 suggests that assumption deserves much closer scrutiny.
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.