BTCPay Server Patches Critical LND Credential Bug After Lightning Wallet Drain

BTCPay Server has released version 2.4.2 to patch a critical vulnerability that allowed unauthenticated remote access to LND credential files, after attackers used the issue to drain merchant Lightning wallets.

The project’s release notes describe a serious bug involving .macaroon files, which are used by LND to manage access permissions. In plain English, those files can act like keys. If an attacker gets hold of the wrong one, they may be able to interact with a Lightning node in ways the operator never intended.

BTCPay supporters have also backed a recovery bounty equal to 10% of returned funds, capped at 3 BTC. At current prices, that puts the maximum reward around $190,000.

This is not a Bitcoin protocol exploit. It is not a native on-chain wallet failure. It is a server-side security issue affecting certain BTCPay Server setups using LND.

That distinction matters.

For more details, visit the official Github platform.

TL;DR

• BTCPay Server v2.4.2 patches a critical LND credential exposure issue.
• Attackers reportedly drained merchant Lightning wallets through vulnerable setups.
• A recovery bounty offers 10% of returned funds, capped at 3 BTC.

Why The LND Credential Issue Matters

BTCPay Server is popular because it lets merchants accept Bitcoin payments without relying on a centralized payment processor.

That self-sovereign model is powerful, but it also means server security matters. When a merchant runs their own payment infrastructure, they are also responsible for keeping that infrastructure updated and properly configured.

The vulnerability patched in v2.4.2 is serious because LND macaroons can grant access to node functions. Depending on the permissions attached, an exposed macaroon can be extremely sensitive.

For Lightning operators, credential security is as important as private-key security in practical terms. A wallet can be technically sound, but if a server leaks access credentials, funds can still be at risk.

This Was Not An Attack On Bitcoin Itself

It is easy for infrastructure exploits to get misread.

When people hear that Bitcoin payment servers were drained, they may assume something broke in Bitcoin. That is not what this story shows.

Bitcoin’s base protocol was not exploited. The issue involved BTCPay Server deployments using LND and the exposure of credential files. That makes it an application and infrastructure security event, not a failure of Bitcoin consensus or the Bitcoin blockchain.

That does not make it minor.

For affected merchants, the difference may not feel comforting. Lost Lightning funds are still lost funds. But accurate framing matters because the remedy is different. Bitcoin does not need a protocol patch for this. BTCPay Server operators need to update, check configuration, and secure node credentials.

Lightning Infrastructure Has Different Risks

Lightning is designed for faster, cheaper Bitcoin payments, but it introduces operational complexity.

Node operators deal with channels, liquidity, backups, remote access, routing, credentials, and server exposure. That creates a different security model from holding BTC in cold storage.

A merchant running Lightning infrastructure is not simply holding Bitcoin. They are running live payment software connected to the internet.

That can be safe when managed properly, but it requires discipline. Updates matter. Permissions matter. Credential storage matters. Monitoring matters.

The BTCPay incident is a reminder that self-hosted payment systems are not “set and forget” products.

The Bounty Is A Recovery Attempt

The recovery bounty adds another layer to the story.

Offering 10% of returned funds, capped at 3 BTC, is an attempt to create an incentive for recovery or information. That may help if attackers, intermediaries, or people with knowledge of the funds decide cooperation is better than continued exposure.

Bounties do not guarantee recovery.

They can, however, create a channel for negotiation or disclosure. Crypto projects often use them after exploits because stolen funds can be traceable, exchange deposits can be monitored, and attackers may face difficulty cashing out cleanly.

For affected merchants, the bounty is not a complete solution. The more immediate step is making sure vulnerable systems are patched.

What Operators Should Take From This

The practical lesson is simple: update BTCPay Server and review LND exposure.

Operators should not assume that because a system has worked for years, it is safe indefinitely. Payment infrastructure lives in a changing threat environment. Attackers look for old versions, misconfigurations, leaked credentials, weak permissions, and internet-exposed services.

BTCPay Server remains an important tool for Bitcoin merchants, but self-custody and self-hosting come with responsibilities.

Version 2.4.2 is the fix point for this issue. Anyone running affected setups should treat the update as urgent.

Bitcoin payments can be sovereign, but sovereignty includes maintenance.

This article is based on BTCPay Server’s v2.4.2 release materials and the project’s recovery-bounty details.

This article was written by the News Desk and edited by Samuel Rae.