Skip to navigation

Threat reportVulnerabilityTL-2026-5028

Active Exploitation of BTCPay Server Instances Draining Bitcoin Hot Wallets (Versions Older Than 2.4.2)

highACTIVE

On 2026-11-01 BTCPay Server told operators to shut down after reports that hot wallets on self-hosted instances were being swept by attackers who had obtained administrator-level access. Affected deployments ran releases older than 2.4.2; the entry vector is not yet confirmed and the investigation is ongoing.

Key facts for BTCPay Server hot wallet drain

IdentifiersTL-2026-5028
SeverityHIGH
First disclosed
Exploitation statusExploited in the wild
Affected productsBTCPay Server BTCPay Server (self-hosted); BTCPay Server NBXplorer
MITRE ATT&CK techniquesT1078 Valid Accounts, T1190 Exploit Public-Facing Application, T1550.001 Use Alternate Authentication Material: Application Access Token, T1552.001 Unsecured Credentials: Credentials In Files, T1657 Financial Theft
MotivationFINANCIAL
Target sectorsfinance, cryptocurrency, ecommerce, retail
Target regionsGlobal
Detection rules9 (1 shown free)
Sources9 cited sources

Detection coverage for BTCPay Server hot wallet drain

As of 2026-11-02, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-5028 across Splunk SPL, Microsoft KQL and Sigma, covering 8 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: BTCPay Server Greenfield API Credential Guessing Followed by Success (TL-2026-5028)

Detects an external client that fails authentication against the BTCPay Server Greenfield API (/api/v1/*) at least 5 times and then succeeds. TL-2026-5028 reports attackers logging in as BTCPay administrator on pre-2.4.2 instances to sweep hot wallets; the entry vector is unconfirmed, and this behaviour covers credential-based access to the administrative API. Requires reverse-proxy access logs.

  • Languages: Splunk SPL, Microsoft KQL, Sigma
  • ATT&CK: T1190, T1078
  • Data sources: nginx_access_logs (index=web sourcetype=access_combined), azure_application_gateway_access_logs
  • Severity: high
  • Confidence: high

Splunk SPL

index=web sourcetype=access_combined earliest=-24h uri_path="/api/v1/*"
| where NOT (cidrmatch("10.0.0.0/8",clientip) OR cidrmatch("172.16.0.0/12",clientip) OR cidrmatch("192.168.0.0/16",clientip))
| eval outcome=case(status=401 OR status=403,"fail", status>=200 AND status<300,"success", true(),"other")
| stats count AS requests, sum(eval(if(outcome="fail",1,0))) AS failures, sum(eval(if(outcome="success",1,0))) AS successes, values(uri_path) AS paths, min(_time) AS first_seen BY clientip
| where failures>=5 AND successes>=1
| convert ctime(first_seen)

Microsoft KQL

AzureDiagnostics
| where TimeGenerated > ago(24h) and Category == "ApplicationGatewayAccessLog"
| where not(ipv4_is_private(clientIP_s))
| where requestUri_s startswith "/api/v1/"
| summarize Requests=count(), Failures=countif(httpStatus_d in (401, 403)), Successes=countif(httpStatus_d between (200 .. 299)), Paths=make_set(requestUri_s, 20), FirstSeen=min(TimeGenerated) by clientIP_s
| where Failures >= 5 and Successes >= 1

Sigma

title: BTCPay Server Greenfield API Authentication Failure From External Source
name: btcpay_greenfield_auth_failure
id: 5c0e7a11-5028-4d0a-9b21-3f6a1c0d5001
status: experimental
description: Base rule for TL-2026-5028. Matches failed authentication (401/403) against the BTCPay Server Greenfield API (/api/v1/) from external sources. The paired correlation rule fires on 5 or more failures from one client within 10 minutes. Failure-then-success is evaluated in the SPL and KQL forms.
references:
  - https://news.bitcoin.com/security/bitcoin-payment-processor-btcpay-hit-by-hot-wallet-theft-reports/
author: AII-Detector — ThreadLinqs Intelligence
date: 2026-11-02
tags:
  - attack.initial_access
  - attack.t1190
  - attack.t1078
logsource:
  category: webserver
detection:
  selection:
    cs-uri-stem|startswith: '/api/v1/'
    sc-status:
      - 401
      - 403
  filter_internal:
    c-ip|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: selection and not filter_internal
falsepositives:
  - Misconfigured integrations or monitoring probes using an expired API key
  - Merchant plugins retrying with a rotated credential
level: medium
---
title: BTCPay Server Greenfield API Authentication Failure Burst
id: 5c0e7a11-5028-4d0a-9b21-3f6a1c0d5002
status: experimental
description: Five or more failed Greenfield API authentications from one client within 10 minutes (TL-2026-5028).
author: AII-Detector — ThreadLinqs Intelligence
date: 2026-11-02
correlation:
  type: event_count
  rules:
    - btcpay_greenfield_auth_failure
  group-by:
    - c-ip
  timespan: 10m
  condition:
    gte: 5
level: medium

Known false positives:

  • Merchant integration with a rotated or expired API key that retries before being fixed
  • Authorized penetration test or vulnerability scan against the BTCPay host

Tuning notes: Replace the RFC1918 exclusions with your corporate and VPN egress ranges; if BTCPay is behind a CDN or proxy, use the X-Forwarded-For field instead of clientip. Adjust the failure threshold (5) per baseline and keep the 24h window equal to the alert schedule. Map index/sourcetype to your proxy log pipeline.

8 more detection rules (Splunk SPL, Microsoft KQL, Sigma) · unlock with TL Creds. Sign up free to unlock the detection rules or query them with the Threadlinqs MCP server (Purple)
  • BTCPay Greenfield API Payment-Method Config and Macaroon Exposure (TL-2026-5028) · unlock with TL Creds
  • BTCPay Unauthorized Admin User or API Key Creation via Greenfield API (TL-2026-5028) · unlock with TL Creds
  • LND/Bitcoin CLI Wallet Sweep Commands on BTCPay Host (TL-2026-5028) · unlock with TL Creds
  • BTCPay Greenfield API Admin Enumeration from External IP (TL-2026-5028) · unlock with TL Creds
  • Docker Exec/Copy of LND Macaroon from BTCPay Containers (TL-2026-5028) · unlock with TL Creds
  • LND Channel Force-Close Commands on BTCPay Host (TL-2026-5028) · unlock with TL Creds
  • LND Macaroon File Access by Copy, Encode or Transfer Tools (TL-2026-5028) · unlock with TL Creds
  • BTCPay On-Chain Hot Wallet Spend via API from External Source (TL-2026-5028) · unlock with TL Creds

Indicators of compromise for BTCPay Server hot wallet drain

As of 2026-11-02, Threadlinqs Intelligence tracks 8 indicators of compromise for TL-2026-5028.

8 indicators of compromise · unlock with TL Creds. Compare plans

How BTCPay Server hot wallet drain works

On the evening of 2026-11-01 (about 22:25 UTC) the official BTCPay Server account announced: "We are receiving reports of hot wallets on BTCPay Servers being swept by unauthorized attackers. If you're running an instance, please shut it down (./btcpay-down.sh) until we complete the investigation." Operators were told to keep instances offline and not restart without an official all-clear.

Preliminary findings, relayed by founder Nicolas Dorier and reported by Bitcoin.com and TokenPost, indicate that affected deployments were running software predating 2.4.2 and that an attacker had logged in as an administrator. How administrator access was obtained has not been determined: stolen credentials, a software vulnerability, or another vector all remain open. Public BTCPay servers running 2.4.7 (released 2026-10-29) were reportedly not attacked. BTCPay has not disclosed the number of affected servers or the amount of bitcoin taken, and no network or file IOCs have been published.

Context that defenders should weigh, without assuming causation: in August 2026 BTCPay Server shipped 2.4.2 (2026-08-07) to fix an issue that was actively exploited to steal LND Lightning macaroon credentials, draining Lightning nodes of Foundation and Citadel21. One technical write-up (pasqualepillitteri.it) attributes that earlier flaw to the Greenfield API Basic Authentication handler checking only for FIDO2 credentials and therefore bypassing TOTP-only two-factor protection, allowing retrieval of admin.macaroon with just an email and password; other outlets describe it more generally as unauthenticated macaroon exposure. That earlier incident affected Lightning (LND) nodes, while the November reports concern on-chain hot wallets. BTCPay has not said whether the November thefts are linked to the August flaw or to the issues fixed in 2.4.7. On 2026-10-29 BTCPay released emergency 2.4.7, reported by Bitcoin.com as fixing 85 vulnerabilities (1 critical, 13 high, 52 medium, 19 low) found via an Anthropic security-scanning initiative; it is not established that these relate to the sweeps.

Risk: any BTCPay instance older than 2.4.2 holding funds in a BTCPay-generated hot wallet should be treated as potentially compromised. Updating alone is not considered sufficient if an instance was already compromised: rotate administrator credentials and API keys, review admin users and logins, and move funds. Classification is category VULNERABILITY, severity HIGH (analyst-assigned from confirmed in-the-wild fund theft; no CVE or CVSS exists).

MITRE ATT&CK techniques by tactic:

Initial Access

T1078 Valid Accounts; T1190 Exploit Public-Facing Application

lateral-movement

T1550.001 Use Alternate Authentication Material: Application Access Token

Credential Access

T1552.001 Unsecured Credentials: Credentials In Files

Impact

T1657 Financial Theft

Remediation for BTCPay Server hot wallet drain

Patches

  • BTCPay Server 2.4.2 or later (fixes the August 2026 LND macaroon / Greenfield issue)
  • BTCPay Server 2.4.7 (2026-10-29), reported to fix 85 vulnerabilities including 1 critical
  • NBXplorer 2.6.10 or later (updated alongside 2.4.2)

Immediate actions

  • Run ./btcpay-down.sh to take the BTCPay Server instance offline and keep it offline until BTCPay completes its investigation and gives an all-clear
  • Do not restart a potentially compromised instance on its own authority
  • Move funds out of BTCPay-generated hot wallets to wallets you control; limit hot-wallet balances to an amount you can afford to lose
  • Review BTCPay server logs and the user list for unexpected administrator logins, new admin accounts, or API keys

Workarounds

  • If external LND access is used, rotate the LND macaroon root key (lncli changepassword --new_mac_root_key) so previously stolen macaroons are invalidated
  • Updating alone does not undo an existing compromise; assume credentials and funds on a pre-2.4.2 instance may already be exposed

Longer-term hardening

  • Keep BTCPay Server, NBXplorer and LND current; run 2.4.7 or later (public servers on 2.4.7 were reportedly not attacked)
  • Rotate administrator passwords and API keys, and enable a second factor on all admin accounts
  • Restrict exposure of the administrative UI and the Greenfield API (/api/v1/*) to trusted networks
  • Monitor for outbound on-chain transactions to unknown addresses and for unrequested Lightning channel force-closures

Affected and fixed versions

  • BTCPay Server — BTCPay Server (self-hosted)
    Vulnerable versions: all releases older than 2.4.2
    Fixed in: 2.4.2 (August 2026 LND macaroon fix); 2.4.7 (2026-10-29; public servers on this version reportedly not attacked)
  • BTCPay Server — NBXplorer
    Vulnerable versions: releases older than 2.6.10 (relevant to the August 2026 incident)
    Fixed in: 2.6.10

Timeline of BTCPay Server hot wallet drain

  • Bitcoin Red Team researchers (@brunoerg, @benthecarman) identify the Greenfield API issue that exposed LND macaroons in earlier BTCPay Server versions (related August incident; link to the November sweeps unconfirmed).
  • BTCPay Server 2.4.2 (with NBXplorer 2.6.10) is released and a public alert issued; the flaw was already being exploited against live servers.
  • locked-ioc-6 (Passport hardware wallet) and locked-ioc-8 report Lightning nodes drained via stolen LND macaroons; CoinDesk reports on the exploitation.
  • BTCPay restricts public remote Lightning access on Docker deployments and advises operators to rotate credentials; total losses and affected-operator count not disclosed.
  • BTCPay releases emergency version 2.4.7 fixing one critical and several lower-severity vulnerabilities (reported as 85 total); BTCPay has not said whether it relates to the later thefts.
  • Founder Nicolas Dorier states preliminary findings indicate affected deployments ran releases older than 2.4.2 and that an attacker logged in as administrator; entry method undetermined; public servers on 2.4.7 were not attacked.
  • At about 22:25 UTC BTCPay Server announces that hot wallets on BTCPay Servers are being swept by unauthorized attackers and tells operators to run ./btcpay-down.sh and stay offline pending investigation.
  • Cyber Security News, Bitcoin.com, TokenPost and others report the incident; BTCPay has not disclosed the root cause, number of affected servers, or amount stolen, and no all-clear has been issued.

Sources cited for BTCPay Server hot wallet drain

Drafted by the Threadlinqs research pipeline from 9 sources; published ; last updated —.

Threadlinqs Intelligence — Real-Time Threat Detection Platform

[ 0 threats ] [ 0 det ] [ CRIT: 0 ] [ HIGH: 0 ]
// threat_feed
$ sort --newest
Showing all threats

Live intelligence console

Threat level

Latest Threats