Summary
A defect in the polkadot{.js} browser extension allowed a connected site to obtain a signature over a transaction of its choosing while the signing prompt displayed an inert off-chain message. The prompt showed no method, destination or amount.
All versions before 0.64.0 are affected.
The issue was reported through the Parity bug bounty programme and is fixed in version 0.64.0, published to the Chrome Web Store and addons.mozilla.org on 31 July 2026.
We are not aware of any exploitation of this issue.
Recommended action
Check which version you are running, and update if you are not on 0.64.0 or later.
Chrome (or Edge / Brave)
- Go to
chrome://extensionsand find polkadot{.js} extension - The version is shown on the card, or click Details
- If it isn’t 0.64.0: turn on Developer mode, top right, then click Update, top left
Firefox
- Go to
about:addonsand open Extensions - Click the gear icon at the top, then Check for Updates
- Click polkadot{.js} extension to confirm it now reads 0.64.0
Browsers usually pick this up on their own within a day or so, but please don’t wait for it.
Until you are on 0.64.0, don’t approve any signing request you didn’t start yourself, and treat requests to sign a message rather than a transaction with particular suspicion.
Impact
Exploitation required the user to visit a site under an attacker’s control, which includes a legitimate site that has been compromised, complete the standard connect step, and approve one signing prompt. Connecting grants a site visibility of account addresses only; the per-signature approval is the control the defect defeated.
Where those conditions were met, the site received a valid signature over an extrinsic it had chosen and could broadcast it. The ceiling is whatever a single extrinsic can do from that account.
The significance lies in the expectation it violated. Off-chain message signing is used widely for sign-in and proof-of-address flows and is generally understood to be incapable of moving funds, so it attracts correspondingly low scrutiny.
Root cause
Signing behaviour and prompt rendering were derived from two different sources.
The background service selected signing behaviour from the message channel a request arrived on. Requests on the raw-message channel are wrapped in a <Bytes> envelope, which is what guarantees a message signature cannot be reinterpreted as a transaction. Requests on the extrinsic channel are signed as transaction payloads, unwrapped.
The signing popup instead selected its rendering from fields on the payload supplied by the requesting site. Neither of those fields influences the bytes that are signed. A request delivered on the extrinsic channel but shaped to look like a raw message was therefore signed as a transaction and displayed as a message. No component on the path reconciled the rendered view against the channel the request arrived on.
Resolution
The request type is now a discriminated union on an explicit channel field, set by the background service from the message type and never derived from payload contents. Consumers narrow through a type guard rather than casting, so the rendered view cannot diverge from the signing path without a compilation error. The extrinsic channel additionally rejects payloads shaped as raw messages, which fails closed.
The fix was verified against the released build rather than against source: the reported payload is rejected before a prompt is displayed, and with that check disabled the same payload renders as a transaction with its call data visible. Ordinary transaction and message signing were confirmed unaffected.
Maintainers of wallets derived from this codebase should verify whether their signing path resolves the rendered view from payload contents rather than from the request channel.
Credit
Many thanks to Sagar Yadav (@sagaryadav8742) for finding and reporting this, with a complete and reproducible analysis and a clear case for its severity. Excellent work, and exactly the kind of report the bug bounty programme exists for.