The Brazilian exchange paused deposits and withdrawals after wallets on at least 10 chains were emptied, days after the $6.3 billion Binance hack.
Hardware wallet maker Foundation and the Bitcoin zine Citadel21 both said their nodes were swept, in some cases hours before the project’s public alert. BTCPay says the flaw under attack is not the one disclosed in its changelog.
Attackers emptied Lightning nodes belonging to BTCPay Server users on Friday, including one run by hardware wallet maker Foundation, after the self-hosted bitcoin payment processor warned that a critical vulnerability was being actively exploited and told merchants to update to version 2.4.2 or shut their servers down.
Because BTCPay is self-hosted, there is no operator who can patch on behalf of its users. Every merchant, exchange and wallet running the software has to apply the fix on its own machine, and the thefts were already underway before the warning went out. The software sits behind bitcoin checkout for Namecheap, which ran $73 million in BTC revenue across 1.1 million transactions through BTCPay between May 2020 and October 2024, along with hundreds of smaller merchants and several wallet backends.
“There is a critical vulnerability being actively exploited on BTCPay Server, which can result in the loss of funds,” the project wrote at 11:51 a.m. ET. “If you are unable to update right away, turn off your BTCPay Server to prevent unauthorized access until you can update.” The post passed 550,000 views within five hours.
Founder Nicolas Dorier published release 2.4.2 the same morning with a one-line warning at the top: “This release contains fix of a critical vulnerability that is being actively exploited. You need to update as fast as you can.” The notes also tell integrators to upgrade NBXplorer, BTCPay’s wallet-tracking backend, to version 2.6.10.
Nodes Swept Overnight
Zach Herbert, chief executive of Foundation, the company behind the Passport hardware wallet, said his node was gone before he read the alert. “How many BTCPay lightning nodes were swept? Our Foundation node was drained overnight by attackers,” he wrote at 2:01 p.m. ET.
Herbert narrowed the damage an hour later: “This was just our BTCPay server that we use for payment processing, the hot wallet was untouched – only the lightning node was drained. All channels were closed and funds were swept.”
hodlonaut, the pseudonymous bitcoin commentator behind the zine Citadel21, reported the same pattern. “This is an ongoing attack on BTCPayserver users. Citadel21’s lightning node was just swept,” he wrote. “Fortunately there were not much funds there.”
At least one other operator described closed channels and drained funds in the replies to BTCPay’s warning. Neither Herbert nor hodlonaut disclosed amounts, and no one has published a tally of how many nodes were hit or how much bitcoin moved.
Found By Losing Money
The flaw surfaced because someone got robbed. Dorier credited Craig Raw, the developer of Sparrow Wallet, for working out what was happening.
“We got extremely lucky that a dev was impacted who could analyze the logs to understand what was going on,” Dorier wrote. “Somehow, this wasn’t found AI scans, but by him losing money. :(“
That cuts against the premise of the Bitcoin Red Team, the volunteer group that has spent this week running AI-assisted audits across bitcoin’s open-source stack and that BTCPay thanked for the disclosure. Dorier said the group’s scans missed it.
“The AI report we got from red team didn’t include this one,” he wrote. “But this bug was really sneaky, I am not surprised a simple scan didn’t find it, or thought it was low risk.”
Not The Bug In The Changelog
BTCPay has not said which flaw is being exploited, and Dorier ruled out the one authentication bug the changelog does disclose. After a user posted a Grok-generated explanation pinning the attack on that bug, Dorier replied: “This bug was found by the Red team, this isn’t the critical bug in question.”
The disclosed bug is a two-factor authentication bypass in Greenfield, BTCPay’s API, fixed on Aug. 4. The handler checked only for FIDO2 hardware keys before enforcing a second factor, so accounts protected by an authenticator app could be reached with an email and password alone and receive an unrestricted permission claim. The browser login screen enforced 2FA correctly the whole time.
Dorier followed that with a breaking change switching off Greenfield basic authentication five minutes after an account is created, reasoning that the scheme is almost never used and that turning it off shrinks the blast radius of related bugs. The release also rate-limits public invoice creation on payment requests, and a commit landed on release day marked nine controller methods across five files as non-routable, removing endpoints reachable over HTTP by accident.
A technical writeup is coming. “We are working with Bitcoin Red Team to fully process the details of vulnerability and will follow up with detail technical post shortly,” core contributor Uncle Rockstar wrote. Dorier, asked about holding details back, said: “I am wondering if it makes sense to wait… now that it is exploited in the wild.”
Refresh Your Macaroons
Patching alone does not close the incident. BTCPay told users to completely refresh macaroons and macaroons.db, the credential files that authorize access to an LND Lightning node, and to refresh authentication strings for other Lightning backends. Anyone who generated a hot on-chain wallet inside BTCPay should move those funds and recreate the wallet.
Kaloudis, whose ZEUS wallet runs on LND, put it more bluntly: “Don’t assume you’re safe after upgrading.”
Stolen macaroons survive a software update. An attacker who copied them before the patch keeps node access until the credentials are destroyed and reissued, which matches what the victims describe: channels force-closed and balances swept rather than the server itself compromised again.
Nine Days, Three Failures
The alert lands nine days into the worst stretch for bitcoin infrastructure security in years.
A 2021 Coldcard firmware bug that routed seed generation to a weak software randomizer has drained roughly $114 million in BTC since July 30 across more than 5,200 addresses, with victims describing the loss of life savings. On Aug. 3, the swap bridge Boltz halted its service indefinitely, saying “attackers now iterate faster than a team our size can find and patch.”
The Bitcoin Red Team formed in response to Coldcard. Calle, who helps run it, said on Aug. 5 that 16 researchers had filed 4,962 findings across 390 projects in 27.5 hours, including 85 critical and 635 high-severity issues.
Bitcoin traded near $64,800 on Friday afternoon, up 0.7% over 24 hours and 2.6% on the week, per CoinGecko, showing no reaction to the disclosure.
The setup was built over several weeks, where the attacker deployed dozens of fake token contracts and fake liquidity pools – a term for a pile of tokens locked on a decentralized exchange – that looked like profitable trades. Some mimicked familiar assets such as wrapped ether (WETH), and dollar-pegged stablecoins USDC and USDT.
That bait did what it was supposed to do. Jaredfromsubway.eth’s bot saw what looked like MEV opportunities and generated approvals for attacker-controlled helper contracts to spend tokens on its behalf. Those approvals were used immediately as part of the trade in earlier tests, but later, the attacker created routes where the approvals stayed open.
This left the attacker with standing permission to pull funds. And they used those open approvals to transfer WETH, USDC and USDT out of Jaredfromsubway.eth’s contracts, draining more than $7.5 million.
Some of the stolen funds were later sent to Tornado Cash, onchain data reveiwed by CoinDesk showed.
The irony was hard to miss, meanwhile.
Jaredfromsubway.eth has long been one of the most visible symbols of toxic MEV on Ethereum. Sandwich attacks cost Ethereum traders about $60 million a year, with 60,000 to 90,000 attacks per month between November 2024 and October 2025.
Make preferred on
Hundreds of Ethereum wallets that had sat untouched for years were drained into the same tagged address, turning old key exposure into this week’s sharpest crypto security warning.
On Apr. 30, WazzCrypto flagged the incident affecting mainnet wallets on X, and their warning spread quickly because the affected accounts did not appear to be freshly baited hot wallets. They were old wallets with quiet histories, some tied to assets and tooling from an earlier Ethereum era.
Over 260 ETH, roughly $600,000, was drained from hundreds of dormant wallets. More than 500 wallets appear to be affected, with losses totaling roughly $800,000, and many wallets have been idle for four to eight years. The related Etherscan address is labeledFake_Phishing2831105, and shows 596 transactions, and records a 324.741 ETH movement to THORChain Router v4.1.1 around the Apr. 30 window.
The constant across them is more important for now: long-idle wallets have been moved to a common destination, while the compromise path remains unresolved.
That unresolved vector makes the drain the strongest warning this week, following a surge in DeFi hacks. Protocol exploits usually give investigators a contract, a function call, or a privileged transaction to inspect.
Here, the central question sits at the wallet layer. Did someone obtain old seed phrases, crack weakly generated keys, use leaked private-key material, abuse a tool that once handled keys, or exploit another path that has yet to surface?
Public discussion has produced theories including weak entropy in legacy wallet tools, compromised mnemonics, trading-bot key handling, and LastPass-era seed storage. One affected user personally raised the LastPass theory.
The practical advice for users is limited but urgent. Idleness does not mitigate private-key risk. A wallet with value depends on the full history of the key, the seed phrase, the device that generated it, the software that touched it, and every place that secret may have been stored.
For users, the response is probably to inventory high-value old wallets, move funds only after setting up fresh key material through trusted hardware or modern wallet software, and avoid entering old seeds into checkers, scripts, or unfamiliar recovery tools. Revoking approvals helps for protocol exposure, including Wasabi’s user warning, but a direct wallet drain points first to key security rather than token approvals.
April widened the control surface
The wallet cluster landed amid April’s crypto exploit tally, which was already elevated. DefiLlama-linked reporting put April at roughly 28 to 30 incidents and more than $625 million in stolen funds. As of May 1, the live DefiLlama API showed 28 April incidents totaling $635,241,950.
A May 1 market thread captured the pressure point: this week’s wallet drains, Wasabi Protocol’s admin-key exploit, and April’s larger DeFi losses all hit control surfaces that ordinary users rarely inspect. The link across the month is architectural rather than attributional.
Admin paths became attack paths
Wasabi Protocol supplies the clearest recent protocol example. The Apr. 30 exploit reportedly drained roughly $4.5 million to $5.5 million after an attacker gained deployer/admin authority, granted ADMIN_ROLE to attacker-controlled contracts, and used UUPS proxy upgrades to drain vaults and pools across Ethereum, Base, and Blast. Early security alerts flagged the admin-upgrade pattern as the attack unfolded.
The reported mechanics put key management at the center of the incident. Upgradeability can be normal maintenance infrastructure. Concentrated upgrade authority turns that maintenance path into a high-value target. If one deployer or privileged account can change implementation logic across chains, the boundary around an audited contract can vanish once that authority is compromised.
That is the user-facing problem hidden inside many DeFi interfaces. A protocol can present open contracts, public front ends, and decentralization language while critical upgrade power still sits in a small set of operational keys.
Signers and verifiers carried the largest losses
Drift pushed the same control problem into signer workflow. Chainalysis described social engineering, durable nonce transactions, fake collateral, oracle manipulation, and a zero-timelock 2-of-5 Security Council migration. Blockaid put the loss around $285 million and argued that transaction simulation and stricter co-signer policies could have changed the outcome.
The Drift case matters here because the path did not depend on a simple public-function bug. It depended on a workflow where valid signatures and fast governance machinery could be turned toward a hostile migration. A signer process became the control surface.
KelpDAO moved the stress test into cross-chain verification. The incident statement described a bridge configuration in which the rsETH route used LayerZero Labs as the sole DVN verifier. Forensic reviews described compromised RPC nodes and DDoS pressure feeding false data to a single-point verification path.
The result, according to Chainalysis, was 116,500 rsETH, worth roughly $292 million, released against a non-existent burn. The token contract could remain intact while the bridge accepted a false premise. That is why a verifier failure can become a market-structure problem once the bridged asset sits inside lending markets and liquidity pools.
AI belongs in the speed discussion
I think Project Glasswing deserves a special mention here for context, separate from causation. Anthropic says Claude Mythos Preview found thousands of high-severity software vulnerabilities and shows how AI can compress vulnerability discovery. That raises the bar for defenders, but the causal record in these crypto incidents points to keys, signers, admin powers, bridge verification, RPC dependencies, and unresolved wallet exposure.
The security implications are still serious. Faster discovery gives attackers and defenders more parallel surface to work through. It also makes old operational shortcuts more expensive because dormant secrets, privileged keys, and single-verifier paths can be tested faster than teams can manually review them.
The repair list is operational
The controls that follow from April sit above and around the codebase.
| Incident | Hidden control point | Failure mode | Practical control |
|---|---|---|---|
| Dormant Ethereum wallets | Old wallet material | Funds moved from long-idle wallets into a tagged address while the vector remains unresolved | Fresh key generation for valuable dormant funds, cautious migration, and no seed entry into unknown tools |
| Wasabi | Admin and upgrade authority | Privileged role grants and UUPS upgrades enabled vault and pool drains | Key rotation, stronger thresholds, bounded admin powers, timelocks, and independent monitoring of upgrade actions |
| Drift | Security Council signer workflow | Pre-signed durable nonce transactions and zero-delay governance enabled fast admin takeover | Higher thresholds, delay windows, transaction simulation, and policy-enforced co-signing |
| KelpDAO | Bridge verification path | RPC poisoning and a 1-of-1 DVN route allowed a false cross-chain message to pass | Multi-DVN verification, cross-chain invariant monitoring, and independent checks outside the same verifier path |
For protocols, the priority is to reduce the amount that any single authority can do at once. That means time locks on admin operations, stronger and more stable signer thresholds, monitored privileged-transaction queues, explicit limits on parameter changes, and co-signing systems that simulate transaction effects before humans approve them.
For bridges, the priority is independent verification and invariant checks. A cross-chain message should be tested against the economic fact it claims to represent. If rsETH leaves one side, the system should verify the corresponding state change on the other side before the destination side releases value. That monitoring needs to exist outside the same path that signs the message.
For users, the repair list is smaller. Move valuable old funds to fresh keys through a process you already trust. Separate that action from protocol-specific approval cleanup. Treat every claim about the wallet-drain root cause as provisional until forensic work identifies a common tool, storage path, or exposure source.
The next test
April proved that the average user’s security checklist is likely incomplete. Audits, public contracts, and decentralized interfaces can coexist with concentrated admin authority, weak signer procedures, brittle bridge verification, and old wallet secrets.
The next quarter will reward proof over decentralization language: constrained upgrade powers, visible timelocks, independent verifier paths, transaction simulation for privileged actions, disciplined access controls, and documented key rotation.
The dormant-wallet drains show the uncomfortable user-side version of the same problem. A system can look quiet while an old control failure waits in the background. April’s exploit wave exposed that layer above the code; the next phase will show which teams treat it as core security before funds move.
