Unofficial community page — not published by or affiliated with BTCPay Server. Verify against the official v2.4.2 release notes. This site will never ask for your seed phrase, private keys, macaroons or passwords.
BTCPay Server has reported a critical vulnerability that is being actively exploited. Funds are at imminent risk. Version 2.4.2 contains the fix. Update immediately. If you cannot update, take the instance offline and leave it offline.
| Patched version | 2.4.2 |
|---|---|
| Exploited in the wild | Yes — confirmed by maintainers |
| Funds at risk | Yes |
| Page updated | 7 August 2026 |
Check the version string in the footer of your BTCPay admin interface. If it is below 2.4.2 you are exposed. Patching closes the vulnerability; it does not reverse a compromise that already happened.
Admin dashboard → Server Settings → Maintenance → Update
Wait for it to complete, refresh, and confirm the footer reports 2.4.2. Standard Docker deployments:
cd btcpayserver-docker && ./btcpay-update.sh
Never run a version below 2.4.2 again. If something stops working after the update, do not roll back — an earlier version puts you back on the exploited release.
Do not back up first. btcpay-backup.sh stops and restarts the stack, so run it only after the
instance is patched or network-isolated. Do not bring an offline, unpatched instance back online solely to create a
backup.
Leave it offline until you can update. An offline server cannot be drained.
cd btcpayserver-docker && ./btcpay-down.sh
docker ps
Confirm no BTCPay-related containers remain running. Do not restart an unpatched instance.
Patching does not undo an earlier compromise. If your instance was reachable while unpatched, treat its credentials as exposed and do both of the following.
Deleting macaroon files does not revoke them. A macaroon is verified against a root key held in
macaroons.db, so that database is the deletion that matters — removing it forces LND to generate a new
root key on restart, which invalidates every macaroon issued before, including any an attacker already copied.
Deleting the files as well makes LND reissue a full, valid set against the new key.
Standard Docker LND on mainnet. This extends BTCPay's
documented reset procedure to cover
all eight default macaroons
rather than the three it names — LND also issues chainnotifier, invoices,
router, signer and walletkit:
docker exec btcpayserver_lnd_bitcoin sh -c '\
rm -f /data/*.macaroon \
/data/data/macaroons.db \
/data/data/chain/bitcoin/mainnet/*.macaroon \
/data/data/chain/bitcoin/mainnet/macaroons.db'
docker restart btcpayserver_lnd_bitcoin
The sh -c wrapper matters: without it the * is expanded by your own shell, on your own
machine, and matches nothing inside the container.
Reconnect external applications with the newly generated macaroons, and treat the old ones as invalid. Rotate the credentials for any other Lightning backend too — regenerate the authentication string, certificate or token at the backend, replace it in BTCPay, and revoke the old one where the backend supports it.
Do not use these paths unchanged for a non-standard container name, another Bitcoin network, or a platform-managed deployment. Use that deployment's documented equivalent.
This applies where BTCPay generated or stored the wallet's seed or private keys on the server. After the instance has been patched or isolated:
Wallets connected watch-only via xpub are not affected — BTCPay never held their spending keys. Those operators should still check recent invoices and payout activity.
On Umbrel, Start9, MyNode, RaspiBlitz or a third-party host, use your platform's own update and shutdown controls and its equivalent of the credential refresh. Do not run the commands above. If 2.4.2 has not reached your platform yet, stop the BTCPay app and leave it stopped until it does. On a third-party-hosted instance you cannot patch it yourself — stop using it until the operator confirms 2.4.2 is installed and Lightning credentials refreshed.
Patching does not remove changes an attacker made before the update. If logs, account activity or configuration changes indicate possible exploitation — or you cannot establish that the instance was unaffected:
BTCPay's own advisory gives two actions: update to 2.4.2, or turn the server off until you can. The macaroon refresh and hot-wallet migration in steps 3 and 4 were reported in press coverage of that announcement and are not in the release notes; they are standard practice after a suspected credential compromise. The vulnerability was reported to the maintainers by @brunoerg and @benthecarman from the Bitcoin Red Team effort.
Unofficial community page, not affiliated with or endorsed by BTCPay Server. Where this page and the official release notes disagree, the release notes are correct. No trackers, no analytics, no cookies, no scripts.