# Hackers Exploit BTCPay Server Flaw to Steal Bitcoin and Litecoin From Hot Wallets (LND macaroon credential exposure)

> A vulnerability in BTCPay Server 2.4.1 and earlier lets unauthenticated remote attackers obtain .macaroon credential files for LND, enabling takeover of Lightning nodes and theft of funds. Wallet drains were reported on 2026-11-01 using a different method than the one fixed in 2.4.2; BTCPay lists 2.4.7 as the latest confirmed secure version.

- **Published:** 2026-11-03T09:48:23Z
- **Last reviewed:** 2026-11-03T09:48:23Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-5138
- **Card image:** https://intel.threadlinqs.com/og/threat/TL-2026-5138.png
- **ID:** TL-2026-5138
- **Severity:** CRITICAL
- **Category:** VULNERABILITY
- **Status:** ACTIVE
- **Detections:** 9 (1 shown free below) · **IOCs:** 11

## Description

BTCPay Server is a self-hosted cryptocurrency payment processor. In August 2026 the project disclosed and patched (2.4.2, released 2026-08-07) a critical issue in its LND (Lightning Network Daemon) integration that could allow an unauthenticated remote attacker to obtain .macaroon credential files. Macaroons are the authorization tokens LND uses to permit software to control a node; possession of a sufficiently privileged macaroon lets an attacker take control of the node and move funds. BTCPay confirmed in-the-wild exploitation of that August flaw: attackers drained Lightning nodes behind BTCPay Server, closing channels and sweeping funds. Victims included hardware-wallet maker Foundation (Passport; CEO Zach Herbert confirmed channels were closed and funds swept) and the publication Citadel21 (which reported only an insignificant amount stored). The issue was reported by members of the Bitcoin Red Team (credited: Craig Raw, Rob Hamilton, Calle, Evan Kaloudis; the advisory credits Craig Raw for disclosure and Team Red for exploit analysis). BTCPay withheld technical details pending operator updates and temporarily blocked remote Lightning access through BTCPay domains, Tor addresses and Docker deployments (e.g. for external wallets such as Zeus). Version 2.4.2 bundles LND 0.21.1 and regenerates macaroons on standard installs; operators with independent reverse proxies, Tor services or forwarded ports had to rotate credentials manually. Other Lightning implementations, non-Lightning deployments and BTCPay's own on-chain wallets were not affected by the August issue, but funds in LND's own on-chain wallet remained at risk. Compromised credentials stay valid after patching until rotated.

On 2026-11-01 a new wave of thefts was reported against servers running 2.4.1 and earlier. According to BTCPay's incident post, a wallet drain occurred at 13:46 UTC, the first theft report was received at 20:56 UTC, and a public warning was posted on X at 22:25 UTC; an investigation update followed on 2026-11-02 identifying affected versions. BTCPay states the attackers used a different method to exploit the vulnerability fixed in 2.4.2; the exact mechanism is not disclosed. In this wave, hot wallets holding keys on the affected servers were compromised and funds were sent to attacker-controlled Bitcoin and Litecoin addresses listed in the IOCs. No CVE, CVSS score, source IP, user agent, transaction ID, stolen total or actor attribution has been published by BTCPay or The Hacker News; severity is analyst-assigned from active exploitation and unauthenticated remote credential theft.

Source-quality caveat: secondary outlets disagree on mechanism. One outlet (thecybersecguru.com) attributes the August issue to a Greenfield API BasicAuthenticationHandler 2FA bypass (checking HasFido2Credential() instead of IsTwoFactorEnabledAsync) that requires valid user credentials, which conflicts with BTCPay's own 'unauthenticated' wording; another (news.txid.uk) reports a 3 BTC bounty and community loss estimates of 20-40 BTC. Neither is confirmed by BTCPay and both are treated as unverified context only.

BTCPay advises operators to create a new wallet and sweep remaining funds, take the compromised server offline and preserve logs, redeploy on a fresh VM with the latest BTCPay Server release rather than updating in place, and replace all exposed credentials (hosting, SSH, API, Lightning). Operators should audit for unauthorized payments, unexpected channel closures, unfamiliar peers and balance discrepancies, check the version shown at the bottom of the admin page, keep hot-wallet balances minimal and hold remaining assets offline.

## MITRE ATT&CK

- T1190 Exploit Public-Facing Application
- T1552.001 Credentials In Files
- T1005 Data from Local System
- T1078 Valid Accounts
- T1550 Use Alternate Authentication Material
- T1657 Financial Theft

## Free detection (Splunk SPL, Microsoft KQL, Sigma)

**BTCPay Server LND Macaroon File or LND Proxy Path Requested from External Source** (`TL-2026-5138-SPL-001`)

Detects HTTP requests from non-RFC1918 sources for LND .macaroon credential files, the LND macaroons.db store, or the BTCPay LND REST/gRPC proxy paths (/lnd-rest/, /lnd-grpc/) on a BTCPay Server front end, split into 'success' (200/206) and 'attempt' outcomes. TL-2026-5138 describes unauthenticated remote retrieval of LND macaroons from BTCPay Server 2.4.1 and earlier (exploitation of a flaw for credential access), leading to Lightning node takeover, channel closures and fund sweeps. A successful response on a .macaroon URI is a strong indicator of credential exposure and should trigger immediate macaroon rotation; repeated attempts indicate active probing.

- **Languages:** Splunk SPL, Microsoft KQL, Sigma
- **ATT&CK:** T1190, T1212, T1552.001
- **Data sources:** nginx access logs (index=web, sourcetype nginx:plus:access / access_combined), CommonSecurityLog (WAF/reverse proxy CEF), Sigma webserver
- **Severity:** critical
- **Confidence:** high

### Splunk SPL

````spl
index=web earliest=-24h (sourcetype="nginx:plus:access" OR sourcetype="access_combined") (uri_path="*.macaroon*" OR uri_query="*.macaroon*" OR uri_path="*macaroons.db*" OR uri_path="/lnd-rest/*" OR uri_path="/lnd-grpc/*") | eval src_ip=coalesce(src, clientip) | eval hit_type=if(like(uri_path, "%macaroon%") OR like(uri_query, "%macaroon%"), "macaroon_file_request", "lnd_proxy_request") | eval outcome=if(status=200 OR status=206, "success", "attempt") | where NOT (cidrmatch("10.0.0.0/8", src_ip) OR cidrmatch("172.16.0.0/12", src_ip) OR cidrmatch("192.168.0.0/16", src_ip)) | stats count min(_time) as first_seen max(_time) as last_seen values(uri_path) as uri_paths values(status) as statuses dc(uri_path) as distinct_paths by src_ip, host, hit_type, outcome | convert ctime(first_seen) ctime(last_seen) | sort - count ```outcome=success with hit_type=macaroon_file_request is confirmed credential exposure: rotate LND macaroons and TLS cert```
````

### Microsoft KQL

```kql
CommonSecurityLog | where TimeGenerated > ago(24h) | where RequestURL has '.macaroon' or RequestURL has 'macaroons.db' or RequestURL has '/lnd-rest/' or RequestURL has '/lnd-grpc/' | where not(ipv4_is_private(SourceIP)) | extend HitType = iff(RequestURL has 'macaroon', 'macaroon_file_request', 'lnd_proxy_request') | extend Outcome = iff(Message has_any ('200', '206') or tostring(AdditionalExtensions) has_any ('status=200', 'status=206'), 'success_or_unknown', 'attempt') | summarize Requests = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), Urls = make_set(RequestURL, 20), Methods = make_set(RequestMethod) by SourceIP, DestinationHostName, DeviceProduct, HitType, Outcome
```

### Sigma

```yaml
title: BTCPay Server LND Macaroon File or LND Proxy Path Requested Over HTTP
id: 6b1f3c52-8e47-4d0a-9a21-5c7d2e94b10a
status: experimental
description: Detects successful web requests for LND .macaroon credential files, the LND macaroons.db store, or LND REST/gRPC proxy paths on a BTCPay Server front end, the exposure path used to steal macaroons and take over Lightning nodes (TL-2026-5138).
references:
    - https://blog.btcpayserver.org/btcpay-server-security-incident-2-4-1-and-earlier/
    - https://blog.btcpayserver.org/security-advisory-btcpay-server-2-4-2/
author: AII-Detector — ThreadLinqs Intelligence
date: 2026-11-03
tags:
    - attack.initial-access
    - attack.t1190
    - attack.credential-access
    - attack.t1212
    - attack.t1552.001
logsource:
    category: webserver
detection:
    macaroon_uri:
        c-uri|contains:
            - '.macaroon'
            - 'macaroons.db'
    lnd_proxy_uri:
        c-uri|contains:
            - '/lnd-rest/'
            - '/lnd-grpc/'
    status_ok:
        sc-status:
            - 200
            - 206
    condition: status_ok and (macaroon_uri or lnd_proxy_uri)
fields:
    - c-ip
    - c-uri
    - sc-status
falsepositives:
    - Legitimate remote Lightning wallets (for example Zeus) connecting through the BTCPay LND proxy
    - Authorized penetration tests against the BTCPay host
level: high
```

**Known false positives:**

- Legitimate remote Lightning wallets such as Zeus using the BTCPay LND REST/gRPC proxy from the operator's own mobile IPs
- Authorized penetration tests or vulnerability scans against the BTCPay host

**Tuning notes:** Allow-list the operator's known remote-wallet source IPs. Any 200/206 on a *.macaroon URI should be treated as confirmed credential exposure regardless of source: rotate LND macaroons and TLS certificate. If a CDN or reverse proxy fronts BTCPay, use the forwarded client IP field instead of the proxy address. The KQL status extraction depends on the CEF mapping of your WAF/proxy; adjust the Outcome logic to the vendor's status field.

### 8 more detection rules (Splunk SPL, Microsoft KQL, Sigma), unlock with TL Creds

- Public Source Connecting to LND gRPC/REST Ports on BTCPay Host (Remote Lightning Exposure) (locked: unlock with TL Creds)
- Command-Line Read, Staging, Exfiltration or Header Replay of LND Macaroons (locked: unlock with TL Creds)
- Attacker Bitcoin/Litecoin Address Seen in Host, Proxy, Network or Process Telemetry (locked: unlock with TL Creds)
- External Access to BTCPay Greenfield Lightning Endpoints (locked: unlock with TL Creds)
- lncli Channel Closure, Wallet Sweep or Tor-Routed Remote Node Control (locked: unlock with TL Creds)
- docker cp or exec Used to Extract LND Macaroon, Wallet or Unlock Files from Container (locked: unlock with TL Creds)
- Non-LND Process Reading LND Macaroon, Wallet or Unlock Files on BTCPay Host (auditd) (locked: unlock with TL Creds)
- LND Channel Closure or On-Chain Sweep Activity and Attacker Address Match (locked: unlock with TL Creds)

Sign up free to unlock the detection rules: https://threadlinqs.com/?modal=signup

## Sources

- [Hackers Exploit BTCPay Server Flaw to Steal Bitcoin and Litecoin From Hot Wallets](https://thehackernews.com/2026/11/hackers-exploit-btcpay-server-flaw-to.html)
- [BTCPay Server security incident (2.4.1 and earlier)](https://blog.btcpayserver.org/btcpay-server-security-incident-2-4-1-and-earlier/)
- [Security Advisory: Update BTCPay Server to 2.4.2 Immediately](https://blog.btcpayserver.org/security-advisory-btcpay-server-2-4-2/)
- [Another Bitcoin infrastructure exploit hits, this time draining Lightning payment servers](https://coindesk.com/tech/2026/08/08/another-bitcoin-infrastructure-exploit-hits-this-time-draining-merchant-lightning-nodes)
- [Attackers Are Draining Bitcoin Lightning Nodes](https://hackmag.com/news/btcpay-lnd-exploit)
- [BTCPay restricts remote Lightning access after attackers steal funds](https://cointelegraph.com/news/btcpay-restricts-remote-lightning-access-after-attackers-steal-funds)
- [Bitcoin Lightning nodes drained as attackers exploit BTCPay vulnerability](https://unchainedcrypto.com/bitcoin-lightning-nodes-drained-as-attackers-exploit-btcpay-vulnerability/)
- [BTCPay Server Vulnerability Is Being Actively Exploited to Drain LND Lightning Nodes](https://thecybersecguru.com/news/btcpay-server-vulnerability-lnd-lightning-nodes/)
- [BTCPay Server posts 3 bitcoin bounty after wallet exploit drains user](https://news.txid.uk/post/btcpay-server-posts-3-bitcoin-bounty-after-wallet-exploit-drains-user)

## Full data

The other 8 detection rules (Splunk SPL / Microsoft KQL / Sigma) unlock with TL Creds; a free account includes daily creds: https://threadlinqs.com/?modal=signup
Indicator values unlock with TL Creds, at a lower price on Red and Purple; AI agents can query rules and IOCs through the Threadlinqs MCP server (Purple): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-5138