Foundation and Citadel21 confirmed their Lightning nodes were drained before v2.4.2 landed. Updating alone does not revoke credentials already stolen.
BTCPay Server confirmed on Friday that a critical vulnerability was being actively exploited against live installations, allowing unauthenticated attackers to steal .macaroon credential files from any LND node behind the software and drain its Lightning channels. Version 2.4.2, released the same day, closes the flaw.
Foundation, the company behind the Passport hardware wallet, had its BTCPay-managed Lightning node emptied overnight while the fix was still being finalised. Chief executive Zach Herbert confirmed the sweep publicly, saying the attackers closed the company's channels and moved the funds. Citadel21, the bitcoin publication associated with pseudonymous commentator hodlonaut, reported the same outcome. Neither on-chain hot wallet was touched, but both operators were named victims before most users had heard the vulnerability existed.
A .macaroon is a credential token, an API key with defined permissions that grants software the right to instruct an LND node. Whoever holds one can open or close channels and move funds. The BTCPay flaw let a remote attacker fetch those files with no authentication and no exposed operator key material. From there, sweeping the channels was routine.
The Bitcoin Red Team disclosed the vulnerability to BTCPay before it went public. The group, which points fuzzing tooling at bitcoin codebases across hundreds of repositories, credited Craig Raw of Sparrow Wallet, Rob Hamilton, Calle, and Evan Kaloudis of ZEUS. Their rationale for pushing the alert once patching was under way was blunt: other researchers will find the same bugs, and sitting on a live vulnerability hands the same window to less cooperative finders. That call is correct. It also means the time between responsible disclosure and active exploitation is now measured in hours, not weeks.
The alert itself was direct. BTCPay founder Nicolas Dorier wrote in the v2.4.2 release notes that the release contains a fix for a critical vulnerability being actively exploited and users need to update as fast as they can. The team asked operators to either update or take their servers offline. Full technical details were withheld while patching was still in progress, which is standard practice but leaves defenders working from partial information about their own exposure.
Most operators will miss the next step. Updating to v2.4.2 stops new access. It does nothing to invalidate credentials already stolen from a previously exposed server. Any operator whose install ran a vulnerable version must revoke LND macaroons at the node level, which destroys the root signing key rather than deleting files, and move any funds held in a BTCPay-generated on-chain hot wallet before recreating it. BTCPay's own bulletin was explicit: if the operator generated a hot on-chain wallet in BTCPay, those funds must be moved and the wallet recreated. An operator who patches and stops there remains compromised.
This incident lands in the middle of a punishing month for bitcoin's self-custody stack. The Coldcard random-number-generation flaw has already swept 594 bitcoin from roughly 500 wallets in a single 25-minute window, with Galaxy's third wave lifting the total losses to 1,367 coins. Ctrl Wallet went export-only six weeks after its Cardano exploit rather than continue as a going concern. The Boltz swap service suspended operations days earlier after AI-assisted probing found a live vector. The bitcoin protocol is fine. The tooling around it keeps failing under adversaries who iterate faster than operators can patch.
BTCPay has not disclosed how many servers were hit or the total bitcoin drained. The postmortem, promised in the coming days, will carry the full technical breakdown. What operators already know is that they had hours, not days, to respond to a critical patch notification, and that patching alone leaves stolen credentials intact. The natural pull, if this pattern continues, is toward custodial Lightning: hosted providers who accept the operational burden that self-hosted BTCPay places on the merchant. That is the wrong direction for a payment stack whose entire point is that no third party sits between the merchant and the coin. Foundation and Citadel21 lost their funds inside a window they could not have known existed. The next operator caught in the same window will have no better warning.
