Fearless Wallet Key Leak: Scope, Recovery and Evidence

Changing a wallet password does not replace the private key that controls an account. En Polkadot Community Foundation’s October 21, 2026 security notice tells people who used the Fearless Wallet browser extension since February 2025 to treat the accounts in it as compromised and create new keys outside that extension. Its response concerns signing authority, not merely repairing an application installation.

Use the foundation’s current notice as the authoritative starting point for affected-account decisions and recovery links. Do not paste a seed phrase into a checker, chat, support form or direct message. A copied private key remains usable by its holder even when the original user changes the password on one wallet interface.

Separate the affected software from the affected accounts

En foundation notice identifies extension versions 3.0.1, 3.0.3, 3.0.4 and 3.0.5. It confirms the Chrome case, says the Firefox extension used the same code, and distinguishes reviewed mobile code from keys reused in the extension. It reports eight users’ potentially related unauthorized transactions totaling 17,286 DOT; that is a reported case total, not a complete independently established loss figure.

Build the review around the account’s authority and history. A removed extension, a renamed account or a fresh password can change what the user sees without changing who can sign for that account. Conversely, a statement about reviewed mobile source is not evidence that a key previously handled by the extension was never copied. Keep the software boundary and key boundary in separate rows.

Why reinstalling the extension cannot revoke a copied key

A wallet password typically protects access to locally stored material. The account’s signing key authorizes blockchain actions. This difference explains why a local password change is not an on-chain revocation of a previously copied key. Whether a particular account supports additional controls depends on that account and chain; do not assume such a control exists for every affected balance.

En published incident account describes offending code introduced in a February 2025 source change and active at different times through October 10, 2026. It warns that affected installed copies can still contain code that could be enabled again. Do not use an unlock of the old extension as a harmless way to satisfy curiosity about the incident.

For an application developer, the durable lesson is to trace where signing authority exists in plaintext or exportable form, which components can observe it and what release controls protect those components. A review that checks only transaction approval screens can miss a key export before any transaction is displayed. That is a general threat-model lesson, not a reproduction of the extension’s code or a claim that we examined a victim device.

Prepare recovery without turning it into another disclosure

Follow the foundation’s current instructions through the notice itself. Establish a trusted device and a maintained wallet before creating replacement authority. Confirm that “new account” means a new keypair, not a new name for the old account. Keep the replacement recovery material offline under the owner’s control, and separate it from the browser profile or machine being investigated.

Inventory the old account’s uses across chains and applications before calling the work complete. Record public account identifiers, relevant balances, restrictions, protocol roles and the owner responsible for each item. Keep private keys and recovery phrases out of this inventory. For a team or treasury, reconcile the plan with its authorized signing and approval process rather than improvising from a social-media reply.

Locked or staked assets require special handling. The foundation notice directs affected users to its linked recovery resources before unstaking and warns that timing can matter. Read the applicable protocol and recovery instructions for the account in question. Do not generalize one unbonding duration or recovery outcome to all chains, pools and lock types.

A destination address is public but still needs careful verification: the intended network, account format and ownership must match the approved recovery plan. Record the expected result before an authorized action and check the actual outcome afterward. A completed inventory does not establish that a locked or stolen asset is recoverable; that outcome requires its own case-specific evidence.

Treat recovery claims as a separate trust boundary

A compromised seed creates a difficult evidence problem: the attacker may be able to produce the same valid signature as the owner. Qubic’s separate weak-seed recovery process explicitly explains why a signature alone cannot establish ownership in that incident. Its process is not the Fearless Wallet process, and its current recovery page should not be used to infer the date, cause or network status of another incident.

The comparison is useful because “prove you can sign” and “prove you are the legitimate claimant” answer different questions once a signing key is compromised. Preserve pre-incident funding records and relevant transaction history through the appropriate official process. Do not post identity documents or exchange receipts publicly to demonstrate ownership to strangers.

En Polkadot notice warns about unsolicited recovery messages and says nobody needs your private keys. Follow recovery links from that notice rather than search ads, replies, shortened links or an account claiming to be support. A familiar logo or a plausible case number does not establish that the recipient is authorized to receive sensitive material.

Document what is known without overstating attribution

If an account shows an action the owner did not authorize, preserve its public transaction hash, chain, timestamp and relevant surrounding activity. Separate the observed action from the proposed explanation. An unauthorized transfer can be real even while its connection to this particular extension remains under investigation.

Similarly, the absence of a visible transfer does not repair exposed signing authority. Keep the prevention decision separate from the loss calculation. This avoids two harmful shortcuts: waiting for a drain before treating a known-exposed key as a problem, and attributing every loss by an extension user to one incident without evidence.

No real wallet, key, malicious extension or victim device was used for an experiment in this article. A toy signing demonstration would not establish the state of an affected account and would add little to the recovery decision. The evidence here is the foundation notice, clearly bounded account-security analysis and a comparison to a separately documented recovery process.

Questions about the Fearless Wallet notice

Does a new password make the old account safe?

• A password change does not replace copied signing authority. Follow the notice’s guidance on new keys and affected accounts.

Does importing the seed into another app create a new key?

• No. A new interface can operate the same old key. Verify that replacement authority is genuinely new.

Are all Fearless mobile installations proved to contain the same code?

• The foundation distinguishes reviewed mobile versions from the extension. Key reuse across them remains a separate exposure question.

Can I share my seed with a recovery agent?

• No. The foundation warns that legitimate helpers do not need it. Use the official notice to identify the appropriate recovery channel.

Is 17,286 DOT a final audited loss total?

• The notice describes users’ potentially related transaction reports. Preserve that qualification rather than converting it into a complete audited loss claim.

The video below introduces an authorized application-testing workflow. It is not a reproduction of this incident or a claim of a dedicated incident detector.

The closeout is an account-by-account record of authority, restrictions, authorized recovery results and evidence still missing. Reinstalling an application can be a maintenance step. Recovering control requires answering who can still sign.