BTCPay flaw actively exploited: updating alone is not enough
A flaw in BTCPay Server authentication let attackers bypass two-factor verification with nothing more than an email address and a password. Version 2.4.2 closes the hole, but updating alone does not make you safe: stolen credentials keep working.
BTCPay Server, the self-hosted payment software that lets webshops accept bitcoin, warned on 7 August 2026 about a vulnerability that was already being actively exploited at the time. Version 2.4.2, released on 8 August, closes the hole. Anyone still running an older version risks losing funds.
The flaw sat in the authentication layer of the Greenfield API. The code checked whether a FIDO2 security key had been registered, rather than whether two-factor authentication was switched on at all. Users with an ordinary authenticator app usually have no FIDO2 key, so for them the API skipped the second step entirely. An email address and a password were enough.
What has already happened
The Lightning node of the BTCPay Foundation itself was drained before the warning went public. The node run by Citadel21, operated by Hodlonaut, went the same way. At least one other operator reported the same thing. No total figure has been released.
The flaw was found by Craig Raw, the developer behind Sparrow Wallet, after his own node was compromised. He traced the attack back through the server logs.
Updating is the first step, not the last
This is the part that most often goes wrong, and here it matters more than the update itself. The login credentials for your Lightning node, known as macaroons, sit on disk as files. An attacker who was inside before the patch may have copied them. They keep working afterwards, because the update changes nothing about that.
Following the project instructions, you also need to replace your Lightning credentials after updating: delete macaroons.db and every macaroon file, then restart your node. On top of that, move the balance of your on-chain hot wallet to a new wallet, and switch any integrations over to API keys with a limited scope rather than full access. The patch now disables Basic Authentication by default, five minutes after an account is created. Alongside BTCPay itself there is a matching update for NBXplorer, version 2.6.10.
What this says about automated testing
There is an awkward detail to this story. The Bitcoin Red Team audit, completed on 5 August, worked through 390 open source projects in 27.5 hours and produced 4,962 findings, 85 of them critical. This flaw was not among them.
That does not make the audit worthless, but it does correct the impression such a number can create. Automated scanning finds the patterns it recognises. A logic error in which the wrong condition is checked, where the code does exactly what it says and what it says is simply wrong, slips past easily. In the end the flaw was found by someone digging through his own logs after being robbed.
What this means for you
If you run a BTCPay instance yourself, the order is this: update to 2.4.2 first via Admin Dashboard, Server, Maintenance, Update, then check the footer to confirm it really does say 2.4.2. If you cannot update straight away, take the instance offline until you can.
After that, replace the macaroons and move your hot wallet. Skip that step and you have changed the lock but left the old key with the previous tenant.
If you do not use BTCPay but do run a webshop that accepts bitcoin, ask your payment provider which version they are running. And the wider lesson, which holds even if you do nothing with Lightning: after a break-in, changing the password is rarely enough. Session tokens, API keys and linked devices keep working until you revoke them yourself.
Sources: BTCPay Server (warning of 7 August 2026), Craig Raw (Sparrow Wallet), TechTimes (8 August 2026), Crypto Briefing. Last checked: 9 August 2026.