CVE Index中文
L4 · Septic Tank BlewBTCPay · Bitcoin · hot walletsbtcpay-hot-wallet-reports

BTCPay confirms old-flaw wallet thefts and requires fresh-server recovery

BTCPay confirms thefts on 2.4.1 and older via a different method for the flaw fixed in August’s 2.4.2. Older or compromised installs need a clean VM, new wallet seed and replacement credentials, even after updating. Bitquery’s ~$1.63m/682 sweeps remain unverified transaction estimates, not victim counts.

Disclosed
Nov 1, 2026
Updated Nov 6, 2026
Severity
CVSS 9.8
1 CVE tracked here
Splash zone
The identified attack path targets BTCPay Server 2.4.1 and older; hot wallets on affected instances are at risk
crypto
In the wild
Yes
BTCPay confirms BTC/LTC thefts targeting 2.4.1 and earlier.

What happened

The project’s November 1 warning is an actionable containment request for operators of a self-hosted payment system. Reports of actual wallet sweeps support L4, while the investigation remains preliminary. The initial alert did not establish how many instances were affected, how much was taken, whether every hot wallet is exposed, or whether the entry point is software, credentials or a deployment component.

Do not infer that cold wallets, every Lightning deployment or the Bitcoin network were compromised. The initial warning named no vulnerability identifier or release. The November 2 observations below narrow the reported version range; they do not establish a complete host-recovery procedure.

November 2 scope update: The project now identifies an attack path against 2.4.1 and older. Dorier reports attackers logging in as administrators, with the entry method still unknown. The project has no credible hot-wallet drain reports on 2.4.7; Dorier says its public servers on that version were not attacked and urges regular updates and small hot-wallet balances. These statements narrow the observed scope without proving all newer instances safe or linking the incident to a specific August vulnerability. Vendor-confirmed loss totals, affected-instance counts and complete recovery instructions remain unconfirmed. A separate complete Dorier post reports traces of pre-2.4.2 vulnerabilities, but does not identify which flaw or combination enabled the admin access.

November 2 tracing update: Bitquery’s original investigation estimates about $1.63 million, approximately 18.38 BTC and 3405 LTC, from 682 sweep transactions. It counts 267 sweeps after the public alert, worth about $150,000 at its chosen prices. These researcher figures have not been independently verified and are not a final project-confirmed loss figure. The count cannot identify servers or people: repeated sweeps may involve the same operator.

Bitcoin coverage ends at block 974216 (November 2, 05:42 UTC); Litecoin coverage ends at 06:00 UTC. The estimate covers the named collection addresses, excludes Lightning and other coins, and leaves out 0.26 BTC received by an associated wallet without reaching the named collector. It values the coins at $78,326/BTC and $55.54/LTC; another valuation date changes the dollar estimate. Bitquery reports more than 99% still in addresses first used in the theft at its cutoff. This is not evidence that funds were frozen, returned or recoverable, and an unlabeled payout address is not proof of an exchange deposit.

The project separately confirms that some hosting providers automatically shut down older instances. Verify your own service state with the provider before any restart; that notice supplies no complete host-cleanup or funds-recovery procedure.

Full November 2 report, verified November 3: This supersedes the earlier incomplete recovery guidance and uncertainty over linkage to the August flaw. BTCPay confirms a different method against the vulnerability fixed in 2.4.2. Servers already at 2.4.2 or later when the November 1 warning was issued showed no observed impact from these attacks. Older installs, including those upgraded only afterward, should move to a fresh VM and new-seed wallet even without visible theft; signs of compromise trigger the same response regardless of present version. Keys kept off the server were unaffected by these thefts, but older-server rebuilding still applies. The project publishes the same BTC/LTC collector addresses and explicitly warns that earlier activity and unresolved attribution prevent treating their balances/history as confirmed losses. Bitquery’s separate estimate above remains source- and time-bounded, not a vendor-confirmed total.

November 6 identifier and scope cross-check: The November 5 CVE record adds an identifier for the August-fixed LND macaroon flaw. The August advisory says ordinary BTCPay on-chain hot wallets and other Lightning implementations are outside that specific credential path; LND’s own on-chain funds can still be exposed. The separate November 2 report explicitly describes a different exploitation method and BTC/LTC hot-wallet thefts. Do not use the August exclusion to declare those older servers safe or infer that all November sweeps were LND withdrawals. Preserve the fresh-VM, new-seed and credential-replacement instructions and the unverified tracing limits above.

What’s in the bowl

LND macaroon credential disclosure in the August-fixed vulnerability

VulnCheck published this identifier November 5 for unauthenticated LND credential-file retrieval before 2.4.2, including release candidates. CVSS 3.1 is 9.8 (CVSS 4.0 is 9.3); this does not independently explain the different November exploitation method.

Fixed versions

ProductSafe fromNote
BTCPay Server minimum for the August LND disclosure2.4.2Excludes 2.4.2 release candidates; use the current supported release, and rebuild compromised hosts
LND in the August BTCPay update0.21.1Verify deployment and regenerated macaroons; separately exposed routes need manual credential rotation

Crime-scene timeline

  1. Nov 1, 13:46 UTC

    Later report dates one reported wallet drain

    The full project report supplies this drain time but says the first exploitation time remains unestablished.

  2. Nov 1, 20:56 UTC

    Project receives its first theft-report email

    This is the project’s first received email, not the start of all attacks or victim exposure.

  3. Nov 1, 22:25 UTC

    Project warns of hot-wallet sweeps and requests shutdown

    The official alert asks instance operators to run ./btcpay-down.sh until the investigation is complete; no patch or restart time is given.

  4. Nov 2, 2026

    Founder reports administrator access on older instances

    Nicolas Dorier says reports appear to involve versions before 2.4.2; how attackers logged in as admin remains under investigation.

  5. Nov 2, 2026

    Project identifies a path targeting 2.4.1 and older

    The readable official update reports no credible hot-wallet drains on 2.4.7. The public embed truncates later guidance; it does not establish a restart procedure.

  6. Nov 2, 2026

    Project confirms some hosting providers shut down older instances

    Operators should check with their provider; the post thanks LunaNode and others without declaring every hosted instance safe.

  7. Nov 2, 2026

    Bitquery publishes a time-bounded BTC and LTC tracing estimate

    The research counts about 18.38 BTC and 3405 LTC across 682 sweeps, including 267 after the initial alert. Bitcoin coverage ends at block 974216 (05:42 UTC) and Litecoin at 06:00 UTC; these are transaction counts, not victim counts.

  8. Nov 2, 2026

    Full project report confirms old-flaw exploitation and recovery steps

    The project ties the attacks to a different exploitation method for the flaw fixed in August’s 2.4.2. It calls for a fresh server, new seed and credential replacement on affected older installs, even after an update or without visible theft.

  9. Nov 5, 2026

    CVE record identifies the August LND credential-disclosure flaw

    CVE-2026-119757 covers unauthenticated .macaroon retrieval before 2.4.2, including release candidates. The August advisory excludes ordinary BTCPay on-chain wallets from that specific path; the November report still requires broader old-server recovery for its different exploitation method.

Who said what

We list each claim and who made it. Primary sources (the vendor, the researcher, the registry) are marked. Where reports disagree, we grade by the worst credible case.