Private Key Leak Archives | Crypto Coin Show

Oct 21, 2026

Polkadot Community Foundation warns Fearless Wallet users of 571-day key exposure

Crypto Coin Show News Team Blockchain, Legal & Crime Browser Extension, Cryptocurrency Breach, DOT Tokens, Fearless Wallet, Polkadot, Private Key Leak, Wallet Security

BlockchainCrypto Coin Show News Team·October 21, 2026·4 min read

The Polkadot Community Foundation disclosed on October 21, 2026, that the Fearless Wallet browser extension leaked private keys for over 20 months, compromising every account created or imported into the tool since February 2025. Institutional users and custodians relying on third-party wallet extensions face renewed pressure to audit key management practices and isolate recovery phrases from internet-connected devices.

Malicious code added February 19, 2025, collected private keys and recovery phrases each time users unlocked the wallet until October 10, 2026, a span of 571 days of active exposure.
Eight users reported 17,286 DOT in unauthorized transfers; version 3.0.5 remained on the Chrome Web Store with 6,000 active installations as of the disclosure date.
The compromised code in versions 3.0.3 to 3.0.5 used a remote kill switch that was turned off October 10, 2026, but could be reactivated at any time on installed instances still containing the payload.

571 days The malicious code remained active between its injection and final disablement
17,286 DOT Reported unauthorized transactions across eight affected user accounts
6,000 users Still running version 3.0.5 on Chrome Web Store at time of disclosure

The Polkadot Community Foundation issued a mandatory security notice advising all users of the Fearless Wallet browser extension to treat every account in the tool as compromised and move funds immediately to a new wallet. According to the foundation’s statement on the Polkadot Forum, code inserted into the extension’s public source repository on February 19, 2025, as part of a larger change titled “TON ecosystem” collected the recovery phrase or keystore file and wallet password each time the wallet was unlocked. The payload encrypted these credentials using an empty password, reversible by anyone with network access, and transmitted them to tonscanner.org, a server controlled by the attacker.

Malicious code ran on a 20-month remote kill switch controlled by the attacker

The offending code was present in four released versions: 3.0.1, 3.0.3, 3.0.4, and 3.0.5. Versions 3.0.3 through 3.0.5 implemented a more sophisticated mechanism: a configuration file stored in a separate public GitHub repository acted as a remote on/off switch, allowing the attacker to activate or deactivate the code without pushing new builds to app stores.

According to a technical analysis published by the polkadot-api team, this switch remained active during nine recorded periods between March 7, 2025, and October 10, 2026. The code was removed from the project’s public source repository on June 25, 2026. However, installed copies of versions 3.0.3 to 3.0.5 retained the payload and continue to check the remote switch on every wallet unlock, leaving the door open for reactivation.

Version 3.0.5 was still available on the Chrome Web Store with approximately 6,000 active users at the time of disclosure on October 21, 2026.

Private keys stolen from any account remain compromised across all chains and wallets

The Polkadot Community Foundation emphasized that a private key or recovery phrase, once leaked, grants total control over an account regardless of which wallet application the user switches to. Changing the extension password or reinstalling the tool does not invalidate a leaked key.

Some users reported unauthorized fund transfers the moment they unlocked the wallet without taking any further action, indicating the attacker monitored compromised accounts in real time.

Staked coins, nomination pool deposits, and locked governance tokens cannot be moved immediately; Polkadot nominators can unbond in as little as one or two days. The foundation recommended that affected users generate a new keypair in a different well-maintained wallet, it suggested Nova Wallet, and transfer funds across all blockchains where the compromised account was active.

It also warned that no legitimate recovery service requires a user’s private keys and cautioned against scammers impersonating support agents.

The foundation noted that Fearless Wallet is a third-party application built by an independent team and has never been an official Polkadot wallet.

Institutional key management practices face audit pressure from wallet extension vulnerabilities

The Fearless Wallet breach represents a critical failure in third-party browser extension security that mirrors earlier compromises in crypto custody tooling. Unlike Mt. Gox’s centralized custodial failure, this attack exploited a development supply chain, the public GitHub repository where the extension’s code was maintained. The code was merged from GitHub pull request #1022 into the extension’s public source.

For institutional investors, the incident underscores a structural problem: browser extensions operate with ambient authority to the entire keystore and can exfiltrate keys without explicit user action or on-chain evidence. Even if an exchange or custodian audits wallet code once, a single unreviewed commit can compromise thousands of users for months.

The 20-month window between code injection and discovery raises questions about how closely extension maintainers and app store moderators monitor actively used security-critical tools. No evidence suggests the Chrome Web Store or Firefox conducted independent security audits of the extension’s source code before listing or updating versions 3.0.3 through 3.0.5.

The foundation’s recommendation to move to Nova Wallet or keep keys offline addresses symptom rather than root cause: if a third-party extension is compromised, the distribution mechanism itself remains trustworthy only if maintainers and platforms enforce code review standards that Fearless Wallet apparently did not meet.

The material open question is how the malicious code came to be merged into the public repository.

The CCS read. We hold that institutional users should treat browser extensions as deprecated for any funds exceeding operational need, regardless of reputation. The Fearless breach was not a zero-day but a 571-day supply chain compromise hidden in plain view of a public GitHub repository. App stores do not conduct code review at deployment. Hardware wallets and air-gapped signing remain the only architecture that prevents this class of attack entirely.

The Polkadot Community Foundation has not disclosed the attacker’s identity or whether law enforcement has been engaged. The foundation will likely face pressure to publish a post-mortem examining how the malicious pull request was merged and why no security review flagged the exfiltration code. The more urgent open question is whether the remote kill switch remains under the attacker’s control or whether Polkadot infrastructure maintainers have secured it, if the former, the vulnerability could be reactivated against all 6,000+ users still running affected versions.

Get this in your inboxThe Crypto Coin Show newsletter covers the policy and market moves institutional crypto investors are pricing in.

May 11, 2026

Blockchain

SIGMA bot blamed as attacker drains $200K from trader’s wallets

Crypto Coin Show News Team Blockchain Base, BSC, Ethereum, Private Key Leak, SIGMA Bot, Telegram Bot Security, Unihax0r, Wallet Drain

BlockchainMay 11, 2026·6 min read

A cryptocurrency trader lost $200,000 across three blockchains in May after attackers gained access to private keys generated through a Telegram trading bot called SIGMA, exposing a critical vulnerability in how retail traders manage wallet creation and key storage on centralized messaging platforms. The incident underscores why institutional investors should scrutinize the security infrastructure of third-party tools, particularly bots operating on platforms not designed for key management, before allocating capital or recommending them to clients.

SIGMA Telegram bot created both drained wallets; other wallets not created by SIGMA remained untouched and uncompromised
Attacker swept $125,000 in $POD tokens on Base and $21,000 in $FHE on BSC within 10-30 minutes across three chains
On-chain analysis ruled out smart contract exploit, confirming private key compromise as the attack vector across Ethereum, Base, and BSC

$200,000 total loss across Ethereum, Base, and Binance Smart Chain in single incident
10-30 minutes time window for attacker to drain all three blockchain networks simultaneously
3 chains compromised simultaneously despite wallets created through single Telegram bot

On May 11, crypto trader Unihax0r discovered that attackers had systematically drained two of his cryptocurrency wallets across Ethereum, Base, and Binance Smart Chain, totaling over $200,000 in losses.

The attack was methodical: the attacker gained access to private keys controlling wallets on multiple networks, then executed coordinated withdrawals of token positions within a 10-to-30-minute window. The largest theft involved $125,000 worth of $POD tokens held on Base, followed by $21,000 in $FHE on BSC, with additional losses in Ethereum-denominated assets.

On-chain forensics by analyst @k0braca1 confirmed the attacker had “full control over signing operations” across all three networks, a signature of private key compromise rather than a smart contract vulnerability or approval-based exploit.

SIGMA bot created both compromised wallets while other wallets remained secure

The critical detail connecting the breach to a single point of failure emerged when investigators cross-referenced wallet creation sources. Both drained wallets had been generated through SIGMA, a Telegram-based multichain trading bot that has gained adoption among retail traders seeking streamlined token swaps and portfolio management.

Unihax0r had later imported those same wallets into GMGN (another Telegram trading tool) and Rabby Wallet, a browser-based self-custody extension. However, wallets on Rabby and Jupiter that had not been created by SIGMA remained completely untouched, indicating the compromise was isolated to the SIGMA generation process or its key storage infrastructure.

This selective attack pattern is significant because it rules out broader device compromise, malware affecting the entire wallet ecosystem on the user’s system, or a breach of downstream platforms like Rabby or GMGN where the wallets were later imported.

The attacker did not attempt to access or move funds from non-SIGMA wallets, suggesting targeted knowledge of which keys originated from SIGMA’s infrastructure. Unihax0r confirmed to security researchers that his Telegram account showed no suspicious login sessions, which would have been the case if his Telegram credentials themselves had been compromised.

Community investigators have proposed several possible vectors for the private key leak, including phishing attacks via fake CAPTCHA bots mimicking SIGMA verification prompts, malware or infostealer mallets on the user’s device, browser extensions with malicious code, or direct compromise of SIGMA’s backend infrastructure.

None has been confirmed, but each points to a systemic weakness in how Telegram bots handle private key generation and storage.

Attacker sent gas fees to cover sweeping wallets across three networks

The execution of the attack revealed sophisticated operational planning.

The attacker first transferred a small amount of ETH to the victim’s Ethereum wallet to cover gas fees for token transfers, then systematically withdrew all balances across Ethereum, Base, and BSC. This preparation step, funding gas on the primary network before conducting sweeps, indicates the attacker understood multi-chain wallet structures and possessed detailed knowledge of the victim’s holdings across three separate networks.

On-chain monitoring firms have tracked the stolen assets to an externally owned account controlled by the attacker. Most funds remain sitting on Base, though investigators have noted the attacker has already begun mixing some tokens, likely using privacy-enhancing services or cross-chain bridges to obscure the transaction trail.

Blockchain forensics firms and fraud tracking accounts have offered to assist in tracing the funds, but recovery odds remain minimal once assets reach attacker-controlled wallets with no clear on-chain linkage to regulated exchanges or custodians.

Telegram bots represent structural weak point for key storage and wallet generation

The SIGMA incident is not an isolated event but rather the latest in a recurring pattern of losses tied to Telegram trading bot infrastructure. When users generate wallets through Telegram bots, private keys are created and stored within the bot’s server architecture, bypassing traditional hardware wallet or local key management best practices.

Security researchers from ForkLog have issued repeated warnings about this architectural flaw, noting that Telegram bots “could potentially lead to asset losses and are not safeguarded against hacker attacks.”

The vulnerability stems from a fundamental mismatch between Telegram’s design and cryptographic security requirements. Telegram is a messaging platform built for communication, not key custody. Bots running on Telegram operate in an environment designed for transient conversations, not persistent, encrypted key storage.

When a user’s private keys are generated and held server-side by a bot, rather than created and stored locally by the user or on a hardware device, the bot operator becomes a single point of failure.

A breach of the bot’s infrastructure, a phishing attack targeting users of the bot, a malicious insider, or a compromise of Telegram itself could expose thousands of users’ private keys simultaneously.

For institutional investors and advisors considering Telegram bots as a client onboarding tool or trading solution, the SIGMA incident should trigger a formal security review. The convenience of bot-based wallet creation comes at the cost of surrendering key custody to a third party operating on an unsuitable platform.

Unlike regulated custodians that maintain security audits, insurance coverage, and compliance frameworks, most Telegram bots operate with minimal transparency around their infrastructure, backup procedures, or breach response protocols.

Retail adoption of Telegram bots continues despite mounting security warnings

Despite recurring breaches and security warnings from researchers, Telegram bots remain widely used in retail crypto trading because they solve a real usability problem: they lower friction for new traders who lack technical knowledge or hardware wallet infrastructure.

A user can message a Telegram bot, receive a wallet address, fund it with a DEX or bridge transaction, and begin trading within minutes, all without downloading software or managing seed phrases. This ease of use has made bots attractive to a segment of traders for whom self-custody best practices feel burdensome or confusing.

However, ease of use and security are often in direct tension. The same architectural simplicity that makes Telegram bots appealing, centralized key generation and storage, passwordless access via Telegram sessions, seamless multi-chain wallet support, creates the vulnerabilities that enable attacks like the one that hit Unihax0r. Each convenience layer removes a security barrier.

The key open question for institutional players is whether Telegram-based trading solutions will face increased regulatory scrutiny or whether the market will simply continue to accept these breaches as a cost of using unregulated, convenience-focused tooling. Unihax0r’s $200,000 loss is one of many; determining whether this incident catalyzes broader industry standards for bot security, insurance requirements for Telegram-based wallet services, or regulatory intervention remains unresolved. Institutional investors should monitor whether SIGMA or similar bot platforms issue formal incident disclosures and remediation plans, or whether the incident simply fades from public memory as affected users disperse to other Telegram trading tools with identical architectural risks.