Skip to navigation

Threat reportVulnerabilityTL-2026-5138

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

criticalACTIVE

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. First disclosed .

Key facts for BTCPay LND macaroon theft

IdentifiersTL-2026-5138
SeverityCRITICAL
First disclosed
Exploitation statusExploited in the wild
Affected productsBTCPay Server BTCPay Server (LND integration); Lightning Labs LND (Lightning Network Daemon)
ToolsLND (Lightning Network Daemon), Tor - S0183
MITRE ATT&CK techniquesT1005 Data from Local System, T1078 Valid Accounts, T1190 Exploit Public-Facing Application, T1550 Use Alternate Authentication Material, T1552.001 Credentials In Files, T1657 Financial Theft
MotivationFINANCIAL
Target sectorsfinance, cryptocurrency, ecommerce, news - media
Target regionsGlobal
Detection rules9 (1 shown free)
Sources9 cited sources

Detection coverage for BTCPay LND macaroon theft

As of 2026-11-03, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-5138 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 LND Macaroon File or LND Proxy Path Requested from External Source

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

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

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

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. Sign up free to unlock the detection rules or query them with the Threadlinqs MCP server (Purple)
  • Public Source Connecting to LND gRPC/REST Ports on BTCPay Host (Remote Lightning Exposure) · unlock with TL Creds
  • Command-Line Read, Staging, Exfiltration or Header Replay of LND Macaroons · unlock with TL Creds
  • Attacker Bitcoin/Litecoin Address Seen in Host, Proxy, Network or Process Telemetry · unlock with TL Creds
  • External Access to BTCPay Greenfield Lightning Endpoints · unlock with TL Creds
  • lncli Channel Closure, Wallet Sweep or Tor-Routed Remote Node Control · unlock with TL Creds
  • docker cp or exec Used to Extract LND Macaroon, Wallet or Unlock Files from Container · unlock with TL Creds
  • Non-LND Process Reading LND Macaroon, Wallet or Unlock Files on BTCPay Host (auditd) · unlock with TL Creds
  • LND Channel Closure or On-Chain Sweep Activity and Attacker Address Match · unlock with TL Creds

Indicators of compromise for BTCPay LND macaroon theft

As of 2026-11-03, Threadlinqs Intelligence tracks 11 indicators of compromise for TL-2026-5138.

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

How BTCPay LND macaroon theft works

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 techniques by tactic:

Collection

T1005 Data from Local System

Defense Evasion

T1078 Valid Accounts

Initial Access

T1190 Exploit Public-Facing Application

Lateral Movement

T1550 Use Alternate Authentication Material

Credential Access

T1552.001 Credentials In Files

Impact

T1657 Financial Theft

Remediation for BTCPay LND macaroon theft

Patches

  • BTCPay Server 2.4.2 (2026-08-07) fixes the August macaroon exposure and bundles LND 0.21.1
  • BTCPay Server 2.4.7 is stated as the latest confirmed secure version

Immediate actions

  • Update to BTCPay Server 2.4.7 (latest confirmed secure) or later; versions 2.4.1 and earlier are vulnerable
  • Create a new wallet and sweep remaining funds
  • Take compromised servers offline and preserve logs
  • Audit LND for unauthorized payments, unexpected channel closures, unfamiliar peers and balance discrepancies
  • Confirm running version from the bottom of the BTCPay admin page
  • Report losses to local authorities and security@btcpayserver.org

Workarounds

  • Regenerate LND macaroons and rotate credentials; manually rotate for custom reverse proxy, Tor or port-forward setups
  • Disable public LND API access and remote Lightning access until updated

Longer-term hardening

  • Deploy on a fresh VM rather than updating a compromised host in place
  • Keep hot wallet balances minimal and store remaining assets in offline wallets
  • Rotate all exposed credentials: hosting, SSH, API and Lightning

Affected and fixed versions

  • BTCPay Server — BTCPay Server (LND integration)
    Vulnerable versions: 2.4.1 and earlier; all versions before 2.4.2 including release candidates (August flaw)
    Fixed in: 2.4.2 (August flaw); 2.4.7 (latest confirmed secure)
  • Lightning Labs — LND (Lightning Network Daemon)
    Vulnerable versions: Nodes whose macaroons were exposed via BTCPay Server prior to 2.4.2
    Fixed in: 0.21.1 (bundled with BTCPay 2.4.2, macaroons regenerated)

Timeline of BTCPay LND macaroon theft

  • BTCPay Server 2.4.1 released; this and earlier versions are listed as affected by the November exploitation.
  • Per one secondary outlet (thecybersecguru.com, unconfirmed by BTCPay), a security patch for the August issue was merged.
  • Attackers drained Lightning nodes behind BTCPay Server late on Friday, closing channels and sweeping funds; victims included locked-ioc-10 and locked-ioc-11.
  • BTCPay Server 2.4.2 released fixing an issue that let unauthenticated remote attackers obtain LND .macaroon files; bundles locked-ioc-9.
  • CoinDesk reports the exploit; BTCPay confirms funds were stolen and tells LND users to update to 2.4.2 or take servers offline.
  • BTCPay temporarily restricts remote Lightning access (BTCPay domains, Tor, Docker) and advises manual credential rotation for custom setups.
  • news.txid.uk reports a 3 BTC bounty offered for recovery of funds and community loss estimates of 20-40 BTC (unverified by BTCPay).
  • BTCPay receives the first theft report at 20:56 UTC and posts a public warning on X at 22:25 UTC.
  • Wallet drain on an affected server at 13:46 UTC; attackers used a different method than the one fixed in 2.4.2.
  • BTCPay publishes an investigation update identifying BTCPay Server 2.4.1 and earlier as affected.
  • The Hacker News reports ongoing theft of Bitcoin and Litecoin from hot wallets; BTCPay names 2.4.7 the latest confirmed secure version.

Sources cited for BTCPay LND macaroon theft

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