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 2.4.2 — urgent security response

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 version2.4.2
Exploited in the wildYes — confirmed by maintainers
Funds at riskYes
Page updated7 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.

1. Update now

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.

2. If you cannot update right away, shut BTCPay Server down

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.

3. Refresh your LND macaroons

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.

4. Move funds out of any hot on-chain wallet BTCPay generated

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.

Appliance and managed installs

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.

Verify

  1. Confirm the BTCPay footer reports 2.4.2.
  2. Test store checkout and invoice creation with a small amount.
  3. Confirm on-chain and Lightning payment detection are operating normally.
  4. Confirm external LND clients have been reconnected with new macaroons.
  5. Review recent wallet sends, payouts, users, API keys, webhooks and server-setting changes for anything unexplained.

If compromise is suspected

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:

Impersonation during the incident

Sources

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.