What happened

According to BleepingComputer's reporting on the project's statements, the maintainers of BTCPay Server, an open-source, self-hosted cryptocurrency payment processor, began receiving reports on the evening of 1 November 2026 (UTC) of hot wallets being swept by unauthorized parties. The project first asked operators to shut instances down and asked VPS hosting providers to take affected servers offline as a precaution.

The project's incident response later stated that it had identified an attack vector targeting instances running version 2.4.1 (released 23 July 2026) or older. It says it has no credible reports of hot wallet drains on the latest release, 2.4.7. Founder Nicolas Dorier said the attacker obtained administrator-level access on affected instances, and that the investigation was still working out how that login was achieved on versions older than 2.4.2 (released 7 August). The project's own public servers were running 2.4.7 and were not attacked.

Separately, on 29 October the project disclosed a critical vulnerability, reportedly found through Anthropic's Frontier OSS scanner, and shipped 2.4.7 as an emergency security update. The project has not tied that disclosure to the thefts; at the time of writing the exact entry method has not been published, so treat any claim about the root cause with caution.

Why it matters

A payment server with a connected hot wallet is a direct path from application compromise to financial loss. There is no ransom note and no long dwell time: once an attacker holds admin rights, funds can move within minutes, and blockchain transactions cannot be reversed. Small merchants often run these servers on a single VPS with little monitoring, which makes early detection unlikely and makes the logs you still have very valuable.

The lesson also applies beyond this project. Any self-hosted service that holds keys or can move money deserves the same patch urgency as an internet-facing VPN or firewall.

What defenders should check

  • Version: confirm what you run. In the web UI check the footer or the Server Settings page; for Docker deployments check the running image tags. Version 2.4.1 or older is in the affected range named by the project. The project recommends updating to 2.4.7.
  • Exposure: is the instance reachable from the internet, and does it need to be? Put the admin interface behind a VPN or an IP allow list where possible.
  • Hot wallet balance: keep only what you need for near-term payouts and move the rest to cold storage or a hardware-backed wallet.
  • Accounts: list all users with the server admin role, and check for accounts, API keys, or webhooks you do not recognize.
  • Transactions: compare outgoing wallet transactions with expected payouts and refunds. Note destination addresses, timestamps, and amounts.
  • Hosting provider: if your provider took the VPS offline as a precaution, ask what they preserved before you rebuild it.

Follow the project's update path: Server Settings, Maintenance, Update. For Docker installs, the project documents running the btcpay-update.sh script from the btcpayserver-docker directory.

Detection ideas

The following are starting points to adapt and test in your environment, not production-ready rules. Field names depend on how you collect logs.

Reverse proxy access log: look for admin or API activity from addresses that are not yours.

# nginx access log: requests to account and API paths, grouped by source IP
grep -E '/(account|api/v1|server)/' /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30

Web server logs shipped to a SIEM (KQL style, adapt table and columns):

CommonSecurityLog
| where RequestURL has_any ("/api/v1/users", "/api/v1/api-keys", "/account")
| where SourceIP !in (known_admin_ips)
| summarize Requests=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by SourceIP, RequestURL
| order by Requests desc

Wallet side: alert on any outgoing transaction from the hot wallet to an address that is not on your allow list, and on balance drops outside business hours.

Investigation

If you ran 2.4.1 or older and see unexplained outgoing transactions, treat the host as compromised.

  1. Preserve first. Take a disk snapshot or image of the VPS, and copy the reverse proxy, application, and database logs off the host before updating or rebuilding.
  2. Record the timeline. Export the wallet transaction history with timestamps and destination addresses. Match it against login and API events.
  3. Review application data. Export the user list, role assignments, API keys, webhooks, and store settings, and compare them with what you expect.
  4. Check the host. Look at SSH logins, new users, cron entries, and unexpected processes or containers. The project has not said the attackers touched the operating system, so verify rather than assume either way.
  5. Rotate secrets. After evidence is preserved, rotate admin passwords, API keys, and any credentials stored on the server, and move remaining funds to a new wallet whose keys were never on the host.
  6. Report. The project asks affected users to send details and logs to security@btcpayserver.org and to report losses to local authorities.

Mitigation

  • Update to BTCPay Server 2.4.7 (or later) as the project advises. If you cannot update immediately and run 2.4.1 or older, the project recommends taking the instance offline.
  • Restrict who can reach the admin interface, and require strong, unique admin credentials with two-factor authentication.
  • Keep hot wallet balances small and sweep regularly.
  • Monitor logins and outgoing transactions, and send logs off the host so an attacker cannot erase them.
  • Subscribe to the project's security announcements and set a patch window measured in days for services that hold money or keys.

If you need help investigating a suspected compromise, our incident response and digital forensics teams can assist. Details may change as the project publishes more of its investigation, so check the official BTCPay Server advisory for updates.