A Bug in a Bitcoin Payment Server Let Thieves Drain Nodes

The bug did exactly what a bitcoin payment tool is never supposed to do: it let a stranger spend other people’s money. In early August, BTCPay Server — the open-source payment processor that hundreds of thousands of merchants run to accept bitcoin without a middleman — disclosed a critical vulnerability that attackers had already used to drain funds from Lightning nodes.

The flaw sat in deployments running the Lightning Network Daemon, or LND. Versions of BTCPay Server before 2.4.2 let attackers exfiltrate the .macaroon credential files that grant API access to a node. With those tokens in hand, the thieves bypassed the node’s encryption, force-closed its payment channels, and swept the balances to outside addresses. Hardware-wallet maker Foundation and the bitcoin publication Citadel21 both confirmed their nodes were compromised before anyone understood what was happening.

What broke, and how they stopped it

BTCPay’s developers shipped version 2.4.2 as an emergency patch, forced an upgrade of the bundled LND to 0.21.1, and told every operator to regenerate credentials on the assumption that the old ones were burned. The fix also tightened the Greenfield API and closed a bypass in the time-based one-time-password used for two-factor login. As a blunt containment measure, the team disabled remote access to the node API on Docker deployments — the setup most self-hosted merchants use — which cut off connections for routing wallets like Zeus until operators updated.

None of this is exotic. A macaroon is just a bearer token; whoever holds it can command the node. The failure was that a web application exposed those tokens to an attacker who should never have been able to read them. Once a Lightning credential leaks, there is no chargeback and no reversal — the channels close and the sats are gone.

The uncomfortable part

This is the second high-profile self-custody failure in weeks. It follows a vulnerability in the Coldcard hardware-wallet ecosystem that produced a confirmed nine-figure loss earlier in the summer. The two incidents are technically unrelated, but they rhyme: the tools that let people hold and accept bitcoin without a custodian are software, and software has bugs.

A Lightning routing node is a particularly demanding thing to run safely. Unlike a cold wallet that can sit offline, a node must keep signing keys on a machine that is always online, always reachable, and always one unpatched dependency away from trouble. For a hobbyist that is an acceptable risk. For a commercial operator processing real volume, an incident like this is exactly the kind of loss that ends the experiment.

Where it pushes people

The rational response for a merchant who prioritizes not losing money over ideological sovereignty is to hand the hard part to someone else — to migrate payment flows to a custodial “Lightning-as-a-service” provider that runs the nodes, patches the software, and absorbs the operational risk. That is a reasonable business decision. It is also a quiet centralizing pressure on a network whose whole premise is that you do not need to trust an intermediary.

The counterargument is that open-source infrastructure gets safer precisely because failures are public. BTCPay disclosed the bug, shipped a patch, and forced upgrades within days; a closed processor might have buried the same incident. Responsible disclosure is the mechanism working, not failing. But the lesson for anyone choosing between running their own rail and renting one is now priced in blood: sovereignty at the payment layer is not free, and the bill arrives without warning.

Why it matters: every exploit that drains a self-hosted node is a nudge toward custodians — the exact intermediaries bitcoin was built to route around.

Details of the exploit (affected versions before 2.4.2, macaroon credential theft, forced LND 0.21.1 upgrade, disabled remote Docker API) are as disclosed by BTCPay Server and reported August 7–10, 2026. Node compromises confirmed by Foundation and Citadel21. Informational only — not security or financial advice; operators should follow the official advisory.