BTCPay Server says hot wallet thefts hit 2.4.1 and older via the 2.4.2 flaw; method and losses not stated

The fix was public for 85 days before the first drain the project describes

BTCPay Server's own incident post of 2 November 2026 says the attackers "used a different method to exploit the vulnerability fixed in 2.4.2, released on 7 August 2026". The same post dates a wallet drain described in the incident reports at 13:46 UTC on 1 November. The GitHub release API stamps version 2.4.2 at 15:31 UTC on 7 August, so the gap from the fix to that drain is 85 days and 22 hours (derived). Version 2.4.1, the newest build the project says was targeted, had been out for 101 days at that point (derived), and its release notes carry no security wording (derived: the word does not appear in them). On the project's account, the servers hit were running a build more than three months old, not a brand new one.

What that does not establish is the part a defender most wants. The post says "We have not established when attackers first began exploiting the vulnerability." It gives no count of operators, no total of funds, no description of the different method, and no word on whether the thefts needed a login. A separate secondary report says the investigation concerned how an attacker logged in as an administrator on versions older than 2.4.2. That detail comes from BleepingComputer, which attributes it to a post by a project founder on X. The project's own blog post does not repeat it, so it stays labelled as a secondary claim here.

This briefing reads the project's own pages first: its incident post of 2 November, its security advisory of 7 August and its response post of 10 August, plus the GitHub release API and release notes for 2.4.1, 2.4.2, 2.4.7 and the releases between. BleepingComputer and Cointelegraph, both of 2 November, were read as secondaries and are never the source of a fact the project's pages carry. The project's posts on X, which its blog links, were not fetched; where a line below comes from an X post it is taken from the secondary report that quotes it, and says so. Everything was read between 15:46 and 15:49 GMT on Monday 2 November 2026. The situation may have moved since. The CISA Known Exploited Vulnerabilities catalogue (version 2026.10.30, 1,766 entries) holds no BTCPay entry, and the repository's published GitHub security advisory list is empty, so there is no CVE identifier to cite for either the August flaw or this incident as at this reading.

What the project says, and what it leaves out

The post opens with the incident: "On 1 November 2026, we received reports of Bitcoin and Litecoin being stolen from hot wallets on BTCPay Server." It defines the term, "A hot wallet stores the keys needed to spend funds on the server itself." That definition matters: the funds taken were ones whose spending keys sat on the same machine that ran the shop software.

On versions it is plain. "these attacks targeted servers running BTCPay Server 2.4.1 (released on 23 July 2026) or earlier." For everyone else: "we have seen no impact from these attacks on those servers." That refers to servers already on 2.4.2 or later when the project issued its warning on 1 November. BleepingComputer quotes the project's post on X as saying "We have no credible reports of hot wallet drains for users running the latest 2.4.7 release." and Cointelegraph paraphrases it. Both lines are statements about what the project has seen or been told. Neither is a statement that a version cannot be attacked.

Zoom

Three labels in this story do the work of controls, and none of them is one. "Outdated" here means 2.4.1 or earlier: a build at least 101 days old at the first drain (derived). "Attack vector identified" is a statement that the project knows where to look, not a published root cause. And "no credible reports" is a statement about what has reached the project's inbox.

Seven releases between the fix and the warning

The GitHub release API settles the date conflict in the coverage: 2.4.2 was published on 7 August, not the 6th. Neither secondary read for this briefing says 6 August; BleepingComputer says 7 August and Cointelegraph gives no day. The table gives every release from 2.4.1 to 2.4.7 with the wording its notes use for security, and the gap since the release before (derived from the API timestamps).

Zoom

The post's timeline gives the first report and the public warning. At 20:56 UTC on 1 November, in its words, "we received the first email reporting a theft". At 22:25 UTC it "warned the community on X" and asked operators to shut their servers down. That is 1 hour 29 minutes between the first email and the public warning (derived). It also says it contacted VPS hosting providers, including LunaNode, and asked them to take BTCPay Server instances offline as a precaution. On 2 November it reported that those providers had taken instances offline, so some operators may find a server dark that they did not switch off themselves.

The project also concedes the notice problem in one sentence: "We wish we had done more to reach users still running older versions and alert them to the importance of updating." For a self hosted product with no forced update path, that is the real gap between fix day and drain day.

The August advisory and the November post do not read the same

The August security advisory described the 2.4.2 flaw narrowly. It said "The issue could allow an unauthenticated remote attacker to obtain .macaroon credential files for LND", and in the same advisory it said "BTCPay Server's on-chain wallets, including hot wallets, are not affected." It told users of other Lightning implementations, and users with no Lightning at all, that they did not need to update to address that specific risk, while strongly encouraging them to. The 10 August response post repeats that the flaw let an attacker obtain LND admin macaroon credentials.

The 2 November post says the November thefts were from hot wallets and that they came through a different method against the same fixed vulnerability. It does not comment on the August sentence about hot wallets. Two readings fit what is printed, and neither is stated by the project. One is that the August advisory described one consequence of the flaw and November describes another. The other is that the November method is a distinct route that only shares the 2.4.2 fix. The label "inference" applies to both; the project has to say which.

The August advisory also said "We are not publishing technical details yet because operators still need time to update." It also said it would "work on a full postmortem". The project's blog feed, read on 2 November, lists no item with a postmortem in its title among its 88 entries, the newest being the incident post of 2 November. That is an observation about one feed and its titles, not proof that none exists.

One more item sits in the 2.4.2 release notes and deserves care. Besides the critical fix, the notes list "Fix TOTP two-factor authentication bypass via Greenfield Basic authentication (#7491)" and a breaking change: "Greenfield: Disable Basic authentication by default five minutes after account creation". Greenfield is the project's API. The notes do not say these lines relate to the exploited flaw, and the incident post does not say how access was gained. Whether that two factor line has anything to do with the November thefts is therefore not established. It is listed so that an operator who relied on two factor logins knows the same release changed that behaviour.

Updating is not cleaning: the project's own advice for 2.4.1 and earlier

The headline advice is the project's, and it goes further than "update". For operators on 2.4.1 or earlier it says: "we strongly recommend moving to a fresh server with a new wallet, after sweeping any remaining funds from the existing hot wallet." "This applies even if you have not noticed a theft, and also if you updated from one of these versions after the 1 November warning."

The reason is spelled out: "updating alone cannot remove access an attacker may already have gained." And: "An unchanged wallet balance does not rule out an earlier attack." If funds were stolen or there are signs of unauthorised access, the instruction is to "treat the entire machine and its secrets as compromised". One protection is stated: "Funds in wallets whose spending keys are held off the server, including hardware wallets, were unaffected by these thefts."

Version 2.4.7 sits between those two facts. Its notes say it fixes "85 security findings" and thank "Anthropic and its OSS Scanner program for reporting these findings", giving the severities as printed: 1 critical, 13 high, 52 medium and 19 low, which sums to 85 (derived check). They add that the findings use "the report's original severity ratings". The release was published 2 days 23 hours before the drain (derived). The notes list the fixes but do not say that any of them relates to the incident, and the incident post does not mention 2.4.7 at all. So 2.4.7 is a sensible place to be, and the notes do not tie it to this attack.

What to do, in order

The first five items are the project's advice, in its words or close to them. Items marked this site's view are suggestions, not the project's.

Technical details

The project's pages print no exploit detail, no request, no log line and no detection rule for the November thefts, and this briefing adds none. What they do print is copied below exactly, each block attributed to the page that published it and read on 2 November 2026. A defender uses them to anchor a timeline, to find the two reported destination addresses in their own wallet history, and to check which fixes a given build carries.

First, the incident post's own account of what was found and when. All times in the post are UTC. Use it to set the window for your wallet history review.

Our investigation found that these attacks targeted servers running BTCPay Server 2.4.1 (released on 23 July 2026) or earlier. The attackers used a different method to exploit the vulnerability fixed in 2.4.2, released on 7 August 2026.
1 November, 13:46: a wallet drain described in the incident reports occurred. We have not established when attackers first began exploiting the vulnerability.
1 November, 20:56: we received the first email reporting a theft.
1 November, 22:25: we warned the community on X and asked operators to shut down their servers while we investigated.

Second, the two destination addresses the project says were identified in the incident reports. Search your hot wallet's outgoing transactions for them. The project cautions that some activity at these addresses appears to predate the reported thefts and that their balances should not be read as a confirmed total of losses. A match is a strong sign of a drain from your wallet; the absence of a match does not clear a server that ran 2.4.1 or earlier.

Bitcoin: bc1p0f7wmcnesrapznymf9ljdn04pudgmh96sqtrm9vmgqxdh666fh8qvn63r7
Litecoin: ltc1qp49tmfdueyaqrmgrx0uyx4uegyygt8yt02whee

Third, the release stamps from the GitHub release API. Use them to date your build: anything published before the 7 August line is the version range the project says was targeted. The layout below is this site's, the values are the API's published_at fields (derived formatting).

v2.4.1  2026-07-23T10:14:15Z
v2.4.2  2026-08-07T15:31:16Z
v2.4.3  2026-08-24T14:59:28Z
v2.4.4  2026-09-07T13:28:37Z
v2.4.5  2026-10-06T12:12:14Z
v2.4.6  2026-10-26T14:25:21Z
v2.4.7  2026-10-29T13:48:38Z

Fourth, the 2.4.2 release notes lines, which is where the fix and the two factor and Basic authentication changes appear. The notes do not link the last two lines to the exploited flaw.

This release contains fix of a critical vulnerability that is being actively exploited. You need to update as fast as you can.
* Greenfield: Disable Basic authentication by default five minutes after account creation, with opt-in available through account settings and the API (#7492)
* Fix TOTP two-factor authentication bypass via Greenfield Basic authentication (#7491)

Fifth, the August advisory's description of the flaw as it then understood it, and its own checks for LND users. The file extension is the only artifact it gives.

The issue could allow an unauthenticated remote attacker to obtain .macaroon credential files for LND, an implementation of the Lightning Network. Those credentials could be used to take control of an LND node and move funds. The attacks we reviewed targeted only files with the .macaroon extension.
BTCPay Server's on-chain wallets, including hot wallets, are not affected. Funds held in LND's own on-chain wallet are part of the affected LND node and may still be at risk.
Check for payments you did not make.
Look for unexpected channel closures or unfamiliar peers.
Compare your on-chain and channel balances with your own records.

Sixth, the 2.4.7 security notes: the scanner programme credit and the severity table exactly as printed.

Thank you to Anthropic and its OSS Scanner program for reporting these findings and providing reproducers and proposed fixes.
This release fixes 85 security findings from the scan, using the report's original severity ratings:
| Critical | 1 |
| High | 13 |
| Medium | 52 |
| Low | 19 |

Last, the update path the project gives: the menu route and the footer check from the August advisory, and the update script named in its 10 August post.

Server Settings → Maintenance → Update
To confirm that the update completed successfully, check that the admin footer shows BTCPay Server 2.4.2
btcpay-update.sh

Not published as at this reading: any CVE identifier, any GitHub security advisory for the repository, any indicator beyond the two addresses, and any description of the different method.

The question the record leaves open

A fix existed for 85 days and 22 hours before the first drain the project describes. In August the project told operators that on chain hot wallets were not affected by that flaw, and in November it says hot wallets were drained through a different method against the same flaw. How many operators read the August advisory as not applying to them, and what, exactly, was the different method that made it apply?

Key facts