Skip to navigation

Threat reportVulnerabilityTL-2026-5068

BTCPay Server hot wallet thefts via unauthorized administrator access on outdated instances (v2.4.1 and earlier)

criticalACTIVE

BTCPay Server maintainers warned that attackers gained administrator access to self-hosted instances running v2.4.1 (July 23, 2026) or earlier and swept Bitcoin and Litecoin from connected hot wallets. Emergency release 2.4.7 (October 29, 2026) is the recommended fix; no credible drains have been reported on 2.4.7. First disclosed .

Key facts for BTCPay Server hot wallet drains

IdentifiersTL-2026-5068
SeverityCRITICAL
First disclosed
Exploitation statusExploited in the wild
Affected productsBTCPay Server BTCPay Server
ToolsBTCPay Server, LND, NBXplorer 2.6.10
MITRE ATT&CK techniquesT1078 Valid Accounts, T1190 Exploit Public-Facing Application, T1552 Unsecured Credentials, T1657 Financial Theft
MotivationFINANCIAL
Target sectorsfinance, retail, cryptocurrency, ecommerce
Target regionsGlobal
Detection rules9 (1 shown free)
Sources8 cited sources

Detection coverage for BTCPay Server hot wallet drains

As of 2026-11-02, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-5068 across Splunk SPL, Microsoft KQL and Sigma, covering 11 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 Administrator Login From First-Seen Source Followed by Admin-Surface Access

Detects the core behaviour reported for TL-2026-5068: an attacker logging in as administrator on a self-hosted BTCPay Server (v2.4.1 or earlier, patched in 2.4.2/2.4.7) and browsing server-level admin pages. Flags a client IP that completes a successful POST /login (HTTP 302) and then reaches admin-only /server/* or /api/v1/server/* endpoints, where that IP has no history in the preceding 30 days. Entry method is undisclosed, so this keys on the post-compromise admin session, not an exploit payload.

  • Languages: Splunk SPL, Microsoft KQL, Sigma
  • ATT&CK: T1190, T1078, T1133
  • Data sources: nginx_access, web_proxy
  • Severity: critical
  • Confidence: medium

Splunk SPL

index=web sourcetype=access_combined earliest=-30d@d (uri_path="/login*" OR uri_path="/server/*" OR uri_path="/api/v1/server/*")
| eval login_ok=if(method="POST" AND like(uri_path,"/login%") AND status=302,1,0)
| eval admin_hit=if(match(uri_path,"^/(server/(users|maintenance|services|policies|emails|logs)|api/v1/server/)") AND tonumber(status)<400,1,0)
| stats min(_time) as first_seen max(_time) as last_seen sum(login_ok) as admin_logins sum(admin_hit) as admin_surface_hits values(useragent) as user_agents by clientip
| where first_seen>=relative_time(now(),"-24h@h") AND admin_logins>0 AND admin_surface_hits>0
| convert ctime(first_seen) ctime(last_seen)
| table clientip first_seen last_seen admin_logins admin_surface_hits user_agents

Microsoft KQL

let lookback = 30d;
let window = 24h;
let seen = AzureDiagnostics
    | where TimeGenerated between (ago(lookback) .. ago(window))
    | where Category == "ApplicationGatewayAccessLog"
    | where httpMethod_s == "POST" and requestUri_s startswith "/login" and httpStatus_d == 302
    | distinct clientIP_s;
AzureDiagnostics
| where TimeGenerated > ago(window)
| where Category == "ApplicationGatewayAccessLog"
| where (httpMethod_s == "POST" and requestUri_s startswith "/login" and httpStatus_d == 302)
    or (requestUri_s matches regex @"^/(server/(users|maintenance|services|policies|emails|logs)|api/v1/server/)" and httpStatus_d < 400)
| extend IsLogin = iff(requestUri_s startswith "/login", 1, 0)
| summarize AdminLogins = sum(IsLogin), AdminSurfaceHits = count() - sum(IsLogin), FirstSeen = min(TimeGenerated), UserAgents = make_set(userAgent_s, 5) by clientIP_s
| where AdminLogins > 0 and AdminSurfaceHits > 0
| where clientIP_s !in (seen)
| project FirstSeen, clientIP_s, AdminLogins, AdminSurfaceHits, UserAgents

Sigma

title: BTCPay Server Admin-Only Endpoint Accessed From External Source (TL-2026-5068)
id: 6c1f0a52-3b7e-4d1a-9a52-7e0c4d8f1a01
status: experimental
description: Detects successful requests to BTCPay Server administrator-only pages and APIs (/server/*, /api/v1/server/*). Unauthorized administrator access on v2.4.1 and earlier was used to sweep hot wallets in the TL-2026-5068 incident.
references:
    - https://www.bleepingcomputer.com/news/security/btcpay-server-warns-of-hot-wallet-thefts-targeting-outdated-instances/
    - https://blog.btcpayserver.org/btcpay-server-security-incident-response-and-next-steps/
author: AII-Detector — ThreadLinqs Intelligence
date: 2026/11/02
tags:
    - attack.initial-access
    - attack.privilege-escalation
    - attack.t1190
    - attack.t1078
    - attack.t1133
logsource:
    category: webserver
detection:
    selection:
        cs-uri-stem|startswith:
            - '/server/users'
            - '/server/maintenance'
            - '/server/services'
            - '/server/policies'
            - '/server/emails'
            - '/server/logs'
            - '/api/v1/server/'
        sc-status: 200
    filter_internal:
        c-ip|cidr:
            - '10.0.0.0/8'
            - '172.16.0.0/12'
            - '192.168.0.0/16'
            - '127.0.0.0/8'
    condition: selection and not filter_internal
falsepositives:
    - Legitimate BTCPay administrators managing the server from a new ISP or mobile network
    - Uptime or configuration-management tooling calling /api/v1/server/ endpoints
level: medium

Known false positives:

  • Legitimate administrator travelling or changing ISP/VPN exit and logging in from a new IP
  • Newly onboarded operator or contractor performing first server administration

Tuning notes: Adjust index/sourcetype to your reverse-proxy logs (nginx in the BTCPay Docker stack). Trust X-Forwarded-For if BTCPay sits behind another proxy. Shorten or lengthen the 30d baseline and add known admin/VPN egress IPs to an allow-list lookup. BTCPay returns 200 for a failed login and 302 for success; verify that against your logs. Prioritise instances still on 2.4.1 or earlier.

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 Server Server-Level API Used From First-Seen Source · unlock with TL Creds
  • LND Macaroon or [indicator] Created, Copied or Modified by Unexpected Process · unlock with TL Creds
  • Public Source Connecting to LND REST or gRPC Port · unlock with TL Creds
  • BTCPay Server Host Maintenance Action Issued via Admin Interface · unlock with TL Creds
  • Utility Reading or Copying LND Macaroon / [indicator] on BTCPay Host · unlock with TL Creds
  • LND Channel Close or Force Close Activity on BTCPay Lightning Node · unlock with TL Creds
  • BTCPay Server New User or API Key Created via Admin Interface or Greenfield API · unlock with TL Creds
  • BTCPay Server Hot Wallet Spend or Lightning Payment From First-Seen Source · unlock with TL Creds

Indicators of compromise for BTCPay Server hot wallet drains

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

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

How BTCPay Server hot wallet drains works

No CVE has been assigned and the entry method has not been publicly disclosed.

BTCPay Server is a self-hosted, open-source cryptocurrency payment processor. On November 1-2, 2026 the project said it was receiving reports of hot wallets on BTCPay instances being swept by unauthorized attackers. Reports indicate the attacker was able to log in as an administrator on instances running v2.4.1 (released July 23, 2026) or older. Founder Nicolas Dorier said the method used to obtain administrator access had not yet been determined in public reporting, although the project stated it had identified the attack vector without describing it. Bitcoin and Litecoin were drained from hot wallets, whose signing material lives on the internet-connected server. The maintainers said the attacks did not target public servers, and BTCPay's own servers (running 2.4.7) were not attacked. Maintainers asked VPS providers to take affected instances offline and told operators to run the shutdown script or update immediately.

An emergency release, v2.4.7, shipped on October 29, 2026. BleepingComputer reports that a critical vulnerability was discovered via Anthropic's Frontier OSS scanner on that date. Per the GitHub release notes retrieved during research, 2.4.7 fixes 85 findings from Anthropic's OSS Scanner program (1 critical, 13 high, 52 medium, 19 low) and is recommended especially for multi-merchant servers. Whether the October 29 critical finding is the flaw abused in the drains has not been confirmed by the sources; the in-the-wild drains began the evening of October 29 UTC according to the hunt record.

This follows an earlier incident. On August 7, 2026 release 2.4.2 fixed a separate critical vulnerability that was being actively exploited, reported by Bitcoin Red Team members. The August 10 BTCPay blog post describes that flaw as allowing an attacker to obtain LND admin macaroon credentials from affected instances and use them to access connected LND wallets. Lightning nodes were drained, including one run by hardware wallet maker Foundation; Citadel21 also reported compromise. BTCPay later clarified that the flaw under attack differed from the one in its changelog. A recovery bounty of 10% of recovered funds (maximum 3 BTC) was offered for the August incident. The November thefts affect versions older than 2.4.2, so operators who did not apply the August fix remain exposed.

No indicators of compromise (attacker IPs, wallet addresses, domains, hashes), loss figures, victim counts or attribution have been published. Defenders should treat any instance on 2.4.1 or earlier as potentially compromised: take it offline, update to 2.4.7 (Server Settings > Maintenance > Update, or ./btcpay-update.sh for Docker deployments), move funds out of hot wallets and recreate them, rotate LND macaroons and other Lightning backend credentials, and review administrator accounts, API keys and login history. Report losses to security@btcpayserver.org and local authorities.

Source-date caveat: some retrieved GitHub release pages displayed 2024 years for the release dates; the 2026 dates in BleepingComputer, Unchained and Crypto Economy are used here.

MITRE ATT&CK techniques by tactic:

Initial Access

T1078 Valid Accounts; T1190 Exploit Public-Facing Application

Privilege Escalation

T1078 Valid Accounts

Credential Access

T1552 Unsecured Credentials

Impact

T1657 Financial Theft

Remediation for BTCPay Server hot wallet drains

Patches

  • BTCPay Server 2.4.2 (critical fix, Aug 7, 2026; update NBXplorer to 2.6.10)
  • BTCPay Server 2.4.7 (emergency security release, Oct 29, 2026)

Immediate actions

  • Take any BTCPay Server instance running 2.4.1 or older offline immediately (./btcpay-down.sh)
  • Update to BTCPay Server 2.4.7 via Server Settings > Maintenance > Update, or run ./btcpay-update.sh in the deployment directory
  • Confirm the running version in the server footer after updating
  • Move funds out of hot wallets generated in BTCPay and recreate the wallets
  • Report losses and logs to security@btcpayserver.org and local authorities

Workarounds

  • If unable to update, shut down the instance
  • Replace LND admin macaroons, recreate macaroons.db and refresh authentication strings for other Lightning backends

Longer-term hardening

  • Keep large balances in cold storage and regularly sweep excess hot wallet funds
  • Keep BTCPay Server, NBXplorer and Lightning backends on current releases
  • Review administrator accounts, API keys, and authentication logs for unauthorized access
  • Restrict administrative interface exposure to trusted networks or VPN

Affected and fixed versions

  • BTCPay Server — BTCPay Server
    Vulnerable versions: 2.4.1 and earlier
    Fixed in: 2.4.2 (August 2026 critical fix); 2.4.7 (emergency release, October 29, 2026)

Timeline of BTCPay Server hot wallet drains

  • locked-ioc-8 v2.4.1 released; it and earlier versions are the ones affected by the November drains.
  • locked-ioc-8 2.4.2 released with a fix for a critical, actively exploited vulnerability (reported by locked-ioc-6 members); Lightning nodes were drained, including locked-ioc-10's.
  • BTCPay blog post describes the August flaw as allowing theft of locked-ioc-11 admin macaroon credentials; researchers credited and a recovery bounty offered.
  • Emergency release 2.4.7 issued after a critical vulnerability was found via Anthropic's Frontier OSS scanner; hot wallet drains on 2.4.1-and-earlier begin that evening (UTC) per the hunt record.
  • BTCPay maintainers receive reports of hot wallets being swept and ask operators to take instances offline and VPS providers to shut down affected instances.
  • BTCPay states thefts involve versions older than 2.4.2, the attacker logged in as admin, and no credible drains are reported on 2.4.7; BleepingComputer and others report.

Sources cited for BTCPay Server hot wallet drains

Drafted by the Threadlinqs research pipeline from 8 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