BTCPay Server Exploit Drains Bitcoin Lightning Nodes as Operators Rush to Patch

What to Know

• Attackers exploited a critical vulnerability in BTCPay Server that affected deployments running LND for Bitcoin Lightning payments.
• BTCPay urged users running LND to update immediately to version 2.4.2 or take affected servers offline.
• The flaw allowed unauthenticated remote access to LND “.macaroon” credential files, which can give software permission to interact with a Lightning node.
• Attackers used the exposed credentials to take control of affected Lightning nodes, close channels, and move funds.
• BTCPay said standard on-chain wallets, including hot wallets generated inside BTCPay, were not affected by the credential flaw.
• Funds held inside LND’s own on-chain wallet can still be at risk because they sit under the compromised Lightning node.
• Foundation and Citadel21 were among the victims that reported swept Lightning nodes.
• BTCPay credited Bitcoin Red Team members Craig Raw, Rob Hamilton, Calle, and Evan Kaloudis with responsibly disclosing the issue and helping analyze it.
• BTCPay has not disclosed how many users were affected or how much bitcoin was stolen.
• A full postmortem is expected in the coming days, while detailed technical information remains limited to give operators time to patch.

Bitcoin Payment Infrastructure Faces Another Security Shock

Bitcoin payment infrastructure was hit by another serious security incident after attackers exploited a critical vulnerability in BTCPay Server and drained Lightning nodes running LND. The incident affected merchants and publishers that use the Lightning Network to accept fast, low-cost bitcoin payments, adding pressure to an already difficult period for Bitcoin software security.

BTCPay confirmed that funds were stolen and called on anyone running LND behind BTCPay Server to update immediately to version 2.4.2 or take the server offline. The warning was direct because the weakness affected credentials capable of controlling Lightning nodes. Once attackers obtained those credentials, they could interact with the node, close channels, and move funds out of the affected setup.

The vulnerability did not affect every BTCPay deployment in the same way. BTCPay narrowed the scope after its initial warning and said standard on-chain wallets, including hot wallets created inside BTCPay, were not affected by the credential flaw. The exposure applied specifically to deployments using LND, one of the most widely used implementations for operating a Lightning node. However, BTCPay also warned that funds held inside LND’s own on-chain wallet can remain at risk because those funds sit under the compromised Lightning node.

How the BTCPay and LND Credential Flaw Worked

The exploit centered on LND “.macaroon” files. In the Lightning ecosystem, these files function as credentials that authorize software to interact with a node. They are not ordinary documents in practical security terms. If exposed, they can allow an attacker to perform sensitive actions, depending on the permissions granted by the credential and the way the node is configured.

BTCPay said the flaw allowed an unauthenticated remote attacker to obtain these credential files. That means the attacker did not need to be a legitimate logged-in user to access the sensitive material. In the cases reviewed by BTCPay, the attacks targeted those files and then used them to control affected Lightning nodes. The result was not merely a theoretical security failure. Funds were moved, channels were closed, and operators saw balances swept from their Lightning infrastructure.

The incident highlights a key distinction in Bitcoin wallet security. On-chain wallets and Lightning nodes have different operational models, different risk surfaces, and different custody considerations. A standard Bitcoin on-chain wallet holds funds directly on the base layer, while a Lightning node manages payment channels and may also control related on-chain funds. When Lightning credentials are compromised, attackers may be able to act through the node itself, which can make the consequences immediate for channel liquidity.

Victims Report Swept Lightning Nodes

Hardware-wallet maker Foundation was among the known victims. Chief Executive Zach Herbert said attackers drained the company’s BTCPay Lightning node overnight, closing its channels and sweeping the funds. He also said the company’s BTCPay on-chain hot wallet was untouched, reinforcing BTCPay’s later clarification that the incident was focused on LND-linked credentials rather than standard BTCPay on-chain wallets.

Citadel21, the Bitcoin publication associated with pseudonymous commentator hodlonaut, also reported that its Lightning node had been swept. Citadel21 indicated that little money was held there, but the incident still showed how quickly attackers could move once credentials were exposed. For merchants and publishers, even a limited loss can create operational disruption if payment channels need to be rebuilt and customer payment flows are interrupted.

BTCPay has not disclosed how many users were hit or how much bitcoin was taken. That uncertainty leaves the broader impact difficult to measure. Some affected operators may have taken systems offline before funds were moved, while others may not yet have discovered whether their credentials were accessed. Until BTCPay publishes its postmortem, the available picture remains focused on the confirmed attack path, the urgent upgrade guidance, and the public victim reports.

Bitcoin Red Team Disclosure and Fast-Moving Exploit Risk

The vulnerability had already been reported to BTCPay by members of the Bitcoin Red Team, a group of developers that began pointing AI models at Bitcoin codebases this week. The group has filed thousands of findings across hundreds of projects and has also been associated with warnings about 85 critical bugs in Bitcoin software projects. BTCPay credited Red Team members Craig Raw, Rob Hamilton, Calle, and Evan Kaloudis with responsibly disclosing the issue and helping analyze it.

The incident underscores the difficult balance between fast disclosure and operational safety. The Bitcoin Red Team’s stated reason for publishing findings quickly was that people outside the group would arrive at the same bugs. By the time BTCPay’s public warning went out, attackers were already exploiting this vulnerability against live servers. That sequence raises a hard question for open-source infrastructure: how can maintainers warn users fast enough without giving attackers a roadmap before operators have patched?

For Bitcoin businesses, the answer is rarely simple. Lightning payment systems are often deployed to support real-time commerce, which means uptime matters. Taking servers offline can interrupt customer payments, but leaving vulnerable nodes online can expose funds. BTCPay’s guidance reflected that trade-off by presenting two immediate options for LND operators: update to version 2.4.2 or take the server offline.

Why Lightning Operators Are Especially Exposed

The Lightning Network is designed to make Bitcoin payments faster and cheaper by moving frequent transactions away from the base chain and into payment channels. That architecture can be powerful for merchants because it enables instant settlement-like user experiences without waiting for traditional on-chain confirmation flows. But it also means operators must manage always-on infrastructure, channel liquidity, node permissions, and credential security.

Lightning nodes are not passive wallets. They are networked systems that need to communicate, route payments, and manage channel states. That makes the security of credentials especially important. If a credential can instruct the node to act, then the credential must be protected like a key to the funds that the node controls. In this case, attackers were able to obtain credential files through the BTCPay Server vulnerability and then use them against affected LND nodes.

Market participants and technical traders often focus on Bitcoin’s price action, but infrastructure incidents like this matter for adoption as well. Merchants need reliable tools for accepting bitcoin, and users need confidence that payment processors and self-hosted setups can operate safely. A vulnerability that drains live Lightning nodes does not directly change Bitcoin’s monetary policy or base-layer consensus, but it can affect trust in the surrounding software stack.

BTCPay Narrows the Scope but Urges Caution

BTCPay’s clarification that standard on-chain wallets were not affected is important because it limits the scope of the known exposure. Operators using BTCPay for on-chain wallet functions without the affected LND setup are not described as being hit by the same credential flaw. Still, the project’s warning remains urgent for anyone running LND because compromised node credentials can expose Lightning funds and potentially funds inside LND’s own on-chain wallet.

BTCPay has not yet published the full technical details of the vulnerability. The project said operators need time to patch before deeper information is released. That restraint is common in serious security incidents, particularly when exploit activity is already underway. Publishing too much detail too early can make it easier for additional attackers to target unpatched servers.

For now, the immediate operational message is clear. LND users running BTCPay should move to version 2.4.2 or take vulnerable servers offline. Operators should also review whether their Lightning channels were closed unexpectedly, whether funds were moved, and whether any credentials should be considered compromised. In practice, a credential exposure incident is not solved only by patching the software. Affected operators may need to rotate secrets, rebuild nodes, or restore payment infrastructure from safer assumptions.

Security Pressure Builds Across the Bitcoin Software Stack

The BTCPay exploit arrives during a rough week for Bitcoin software projects. The Bitcoin Red Team’s AI-assisted review effort has generated thousands of findings across hundreds of projects, and separate warnings have referenced 85 critical bugs. While not every finding will translate into an active exploit, the volume of disclosures has sharpened attention on the security posture of Bitcoin’s open-source ecosystem.

Open-source software is a foundation of Bitcoin’s resilience, but it also depends on rapid review, responsible disclosure, and prompt patching by operators. Many Bitcoin businesses run infrastructure that combines multiple components, including payment servers, Lightning implementations, wallet software, operating systems, and web-facing services. A flaw in one layer can expose another, as the BTCPay and LND incident demonstrates.

The coming postmortem will be closely watched because operators need to understand not only what went wrong, but how similar credential exposures can be prevented. The key questions include how the unauthenticated access path emerged, what configurations were most exposed, how attackers moved once they obtained macaroon files, and whether additional hardening steps are recommended for future deployments.

What Comes Next for BTCPay Operators

Until BTCPay releases its full postmortem, the priority for affected infrastructure remains containment. Updating to version 2.4.2 is the central instruction for LND users. Taking servers offline is the fallback for operators who cannot patch immediately. Merchants and publishers that rely on Lightning payments may face downtime, channel reconstruction, and internal reviews of how much liquidity they keep online.

The incident also offers a broader lesson for Bitcoin payment businesses: hot infrastructure should be treated as exposed infrastructure. Lightning nodes are useful precisely because they are online and responsive, but that same availability increases the importance of limiting balances, monitoring channel activity, protecting credentials, and applying urgent patches quickly. For larger operators, separating roles and limiting permissions can reduce the blast radius when a component fails.

Bitcoin itself continues to operate, but the software surrounding it remains under active stress. The BTCPay exploit shows that the weakest point may not be the base protocol, but the practical infrastructure that connects users, merchants, and payment flows. For a network built around self-custody and open access, that distinction matters. Security is not only a protocol feature; it is an operational discipline that every node operator must maintain.

Frequently Asked Questions (FAQs)

What happened to BTCPay Server?

Attackers exploited a critical vulnerability in BTCPay Server that exposed LND “.macaroon” credential files. Those credentials allowed attackers to interact with affected Lightning nodes and move funds from them.

Who needs to take action?

BTCPay users running LND need to act immediately. BTCPay urged those operators to update to version 2.4.2 or take their servers offline if they cannot patch right away.

Were standard BTCPay on-chain wallets affected?

BTCPay said standard on-chain wallets, including hot wallets generated inside BTCPay, were not affected by the credential flaw. The exposure applied specifically to deployments using LND.

Can funds inside LND’s own on-chain wallet be at risk?

Yes. BTCPay warned that funds held inside LND’s own on-chain wallet can still be at risk because they sit under the compromised Lightning node.

Which victims have been identified?

Foundation and Citadel21 both reported that their Lightning nodes were swept. Foundation said its BTCPay Lightning node was drained while its BTCPay on-chain hot wallet was untouched, and Citadel21 said little money was held on its swept node.

How much bitcoin was stolen?

BTCPay has not disclosed how many users were affected or how much bitcoin was taken. The known information is that funds were stolen from affected Lightning nodes.

What are LND “.macaroon” files?

They are credential files used by LND to authorize software interactions with a Lightning node. If attackers obtain them, they may be able to control node functions and move funds depending on the permissions involved.

Who disclosed the vulnerability to BTCPay?

BTCPay credited Bitcoin Red Team members Craig Raw, Rob Hamilton, Calle, and Evan Kaloudis with responsibly disclosing the issue and helping analyze it.

When will more technical details be available?

BTCPay has said a full postmortem is due in the coming days. It has limited technical details for now so operators have time to patch vulnerable systems.

Photo by https://kaboompics.com/ on Pexels