A newly disclosed Vultisig browser-extension bug allows a website that has never been connected to the wallet to silently register fake Keplr-compatible chain information and make that data persist for other websites using the same chain ID.
The issue was opened in Vultisig’s public repository at 13:15 UTC on October 4 and affects the extension’s implementation of Keplr’s experimental chain-suggestion functionality.
According to Vultisig issue #5116, a webpage can bypass the normal chain-approval popup by sending a forged bridge request directly to the extension’s background process.
The vulnerable method, addKeplrSuggestedChain, stores the supplied chain configuration but does not independently verify that the user approved it. Approval exists only in the higher-level in-page provider, meaning a webpage that talks directly to the background bridge can skip that step entirely.
The site does not need to have previously connected to Vultisig.
The report does not describe a working fund-theft path today. Vultisig currently does not support transaction signing for these experimentally suggested chains. But the issue creates a persistent cross-site trust problem inside the wallet that could become considerably more serious as that functionality expands.
The First Website to Register a Chain ID Wins
The vulnerability becomes more unusual because suggested-chain information is currently stored per vault rather than per website.
If one site registers a particular chain ID first, Vultisig preserves that entry and ignores later attempts to replace it.
The reproduction supplied by the Vultisig collaborator demonstrates the problem using two websites.
Site A, which has never connected to the wallet, directly sends a background bridge message registering a fake chain with a Bech32 address prefix of evil. No approval popup appears.
When site B later legitimately calls Keplr’s experimentalSuggestChain for the same chain ID using a prefix of good, Vultisig sees that chain as already registered. The expected approval popup therefore does not appear.
Site B subsequently receives the earlier chain information and an address formatted with the attacker-controlled evil1… prefix instead of the prefix it supplied.
A third website that has never connected to the wallet can also query the existing suggested-chain registry.
That turns what looks initially like an approval-popup bug into a broader cross-origin state problem: one website can create wallet configuration that later websites implicitly trust.
The Vulnerable Feature Has Been in the Code Since May
The affected experimental-chain functionality was added to the Vultisig Windows and extension repository on May 12 as part of a wider effort to improve compatibility with Cosmos applications using Keplr-style wallet interfaces.
That implementation introduced persistent suggested-chain storage so chains added by decentralized applications would survive browser restarts.
The intention was reasonable. Many Cosmos applications interact with wallets through Keplr-compatible APIs, and supporting chains outside a wallet’s hardcoded list requires some mechanism for applications to describe those networks.
The security mistake was placing the approval boundary in the in-page code while leaving the actual background storage method callable without the same authorization check.
The current Chrome Web Store listing shows Vultisig extension version 0.2.27, updated September 28. The vulnerable code remains in the repository’s main branch at the time of the report, while the proposed fix was still an open draft pull request during the October 4 review.
Vultisig’s fix proposal also says the team manually reproduced the pre-fix behavior using a production extension build, strengthening the evidence that this is not merely an unreachable development-code path.
Fake RPC and REST Endpoints Can Also Be Persisted
The Bech32 prefix makes the bug easy to demonstrate, but it is not the only field being stored.
Vultisig persists the complete Keplr ChainInfo object. That includes the chain name, chain ID, currency configuration, address prefix, RPC endpoint and REST endpoint.
The draft fix explicitly notes that per-site isolation is needed so one website cannot determine the “chain info, bech32 prefix and endpoints” later returned for another website using the same chain ID.
That means a malicious page can persist hostile RPC or REST endpoint values alongside the fake prefix.
There is an important limitation, however. Vultisig currently strips endpoint information when dApps call getChainInfoWithoutEndpoints, and suggested-chain signing is not yet implemented. The surfaced code therefore does not establish that Vultisig currently sends sensitive wallet traffic to an attacker-controlled RPC server as a result of this bug.
The endpoints are poisoned in storage, but the report does not demonstrate a present execution path that turns that poisoning into stolen funds.
Vultisig Already Has a Fix Under Review
A draft fix, pull request #5117, was opened shortly after the disclosure.
The proposed change moves chain approval into the extension background process itself rather than trusting the in-page provider to have already shown the user a popup.
Under the new design, the background process validates the proposed chain configuration, opens the approval popup itself and writes the chain to storage only after the user approves.
The patch also restructures storage from a simple vault-level registry into a hierarchy based on vault and website host. In effect, one decentralized application’s suggested chain would no longer be visible to or trusted by another website.
The developers also propose deleting the old suggested-chain registry during migration because existing entries cannot reliably be assumed to have received valid user approval.
The pull request remained in draft status at the latest check and had not yet been merged.
This Is a Trust-Boundary Bug, Not a Private-Key Bug
The most interesting part of the vulnerability is what it says about modern wallet security.
Crypto wallet security is often reduced to one question: can an attacker obtain the private key?
That is increasingly incomplete.
Vultisig uses an MPC architecture specifically designed so a complete private key does not sit inside the browser extension. Yet this bug appears at a different layer entirely: the information the wallet trusts about the blockchain and the website requesting access to it.
The same distinction appeared in the much larger Bitget backend wallet compromise, where investigators said private keys themselves were not stolen even though attackers were able to manipulate infrastructure surrounding the withdrawal process.
The lesson is similar on a much smaller scale. Cryptography can work correctly while the software deciding what the cryptography is supposed to do accepts the wrong input.
The Bug Is Dormant Rather Than Harmless
It would be easy to dismiss the Vultisig issue because suggested-chain signing currently fails.
That would miss the more important risk.
The wallet already stores attacker-supplied chain metadata persistently. It already allows that metadata to affect another website. And it already derives an address using the poisoned Bech32 configuration.
What is missing today is the final capability that would turn that false configuration into an asset-moving workflow.
That makes the vulnerability closer to a dormant security primitive than a complete exploit.
If future releases add signing for arbitrary suggested chains and reuse the same stored configuration, the consequences could change substantially. A hostile RPC endpoint could potentially become more meaningful. Incorrect currency or fee metadata could affect what a user thinks they are approving. A malicious chain definition could potentially sit between a legitimate dApp and the wallet’s signing logic.
This is why fixing the trust boundary before signing support arrives matters more than the absence of theft today.
Self-Custody Moves Risk Into the Wallet Software Layer
The case also illustrates a recurring trade-off in self-custody.
Moving assets away from a centralized exchange eliminates one set of risks, but it makes wallet implementation security much more important. Dave Finances previously examined that problem through the difficulty of measuring losses from compromised self-custody wallets, where there is no centralized operator able to reverse transactions or reconstruct every affected balance.
The same principle applies to browser wallets. The user controls the assets, but the extension still interprets websites, networks, transaction requests and signing prompts on the user’s behalf.
As wallets become broader financial interfaces, that software layer becomes increasingly important. Projects such as self-custodial wallets tied directly to on-chain financial infrastructure are pushing wallets well beyond simple key storage.
Every additional compatibility layer creates convenience, but it also creates another place where assumptions between websites and wallets need to be enforced correctly.
The Fix Needs to Land Before Suggested-Chain Signing Does
For now, the practical impact appears limited to persistent chain-information spoofing, cross-site disclosure of suggested chains, incorrect address presentation and denial-of-service scenarios for applications attempting to register a conflicting chain ID.
There is no evidence in the report that funds have been stolen through the flaw, and the reporter explicitly states that suggested-chain signing is unsupported.
But the discovery is useful precisely because it arrived before that capability exists.
The dangerous sequence would be to add transaction signing first and discover afterward that arbitrary websites had already been allowed to seed trusted chain metadata silently.
Vultisig now has the opportunity to reverse that order: move approval into the trusted background layer, isolate stored configuration by website, discard previously unverified entries and only then expand what suggested chains are allowed to do.
The security question is therefore less about what the bug can steal today and more about whether a cross-site configuration flaw is eliminated before the wallet gives that configuration the power to authorize transactions tomorrow.
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.