Bitcoin payment processor confirms stolen funds: Who are the real risk bearers?

Key Points

BTCPay confirms that the vulnerability has been exploited.

Users using LND and versions lower than 2.4.2 must update.

Other Lightning configurations were not specifically affected.

Users should check nodes after updates.

What actually happened?

Attackers do not need to crack Bitcoin's cryptography or obtain seed phrases. BTCPay said the vulnerability could allow an unauthenticated remote attacker to obtain LND's.macaroon files. These files contain permissions for interacting with the LND node. If the stolen credentials have sufficient privileges, an attacker can perform operations on the node, including operations involving funds.

The attack reviewed by BTCPay targeted files with the.macaroon extension. The project has confirmed that users have been affected and funds have been stolen, but will not release full technical details until the operator has time to patch the system.

Who is really affected?

Users running LND on versions of BTCPay Server before 2.4.2 (including 2.4.2 candidate versions) should consider their installation affected and update it immediately.

BTCPay stated that other Lightning implementations will not be affected by this specific LND credential issue. The same is true for installations that do not use Lightning, but the project still strongly recommends updating older versions of BTCPay Server.

BTCPay's own on-chain wallets (including hot money packages) were not affected by the vulnerabilities identified in the announcement. The LND's own on-chain wallet is different: these funds are part of the affected LND nodes and may still be at risk if node control is breached.

Therefore, the incident is serious, but its confirmation scope is more specific than "all wallets running through BTCPay Server are damaged."

What should BTCPay users do now?

Affected LND users should update to BTCPay Server 2.4.2, which also upgrades LND to version 0.21.1. Any user who cannot update immediately is recommended to take the server offline until it can be updated.

After the patch is complete, users should check what happened on the node before the update. BTCPay recommends checking for outstanding payments, unexpected channel closures, unfamiliar nodes, and differences between expected balances and the current node display.

Credentials may also require attention. Updates will regenerate LND macaroons, but users of nodes who expose them through separately managed infrastructure such as reverse proxies, port forwarding, or Tor services should check these access paths and rotate credentials if necessary.

The reason is simple: installing a patch can close known vulnerabilities, but it is impossible to determine whether credentials have been copied while the server is still exposed. BTCPay has issued additional precautions for different configurations after the incident occurred. Users with more complex configurations should check the latest project instructions and not view software updates as the end point of security reviews.

Broader context

The disclosure comes after an embarrassing week in which Bitcoin holders are already rethinking how to protect their coins. Another Coldcard incident recently sparked renewed discussions about the responsibilities of holding Bitcoin directly. We explored this issue in our analysis of the Coldcard vulnerability and the debate between Bitcoin wallets and ETF custody.

These two incidents involve different security issues. Coldcard involves a hardware wallet environment. The BTCPay vulnerability involves credentials related to Lightning infrastructure. Neither means that Bitcoin itself is compromised. However, their proximity highlights how many components can become important when users are directly responsible for their own coins.

Seed phrases may be completely secure, but software or server credentials provide another avenue for funding. For users running their own infrastructure, hardware security is just part of the job; network exposure, access rights, and software maintenance are equally important.

Some holders may respond by transferring more responsibility to custodians or gaining Bitcoin exposure through ETFs. This eliminates many of the technical tasks faced by individual operators, but makes assets dependent on third-party custody and their protection measures. After two very different security incidents occurred in the same week, the real problem is no longer finding a risk-free method of custody, but more accurately understanding where control lies.

Which device, credential or service can transfer funds? Who controls it? If something is exposed, how quickly can that access be replaced or revoked?

For affected BTCPay users, the top priority is simpler: update the server, check the LND node, and process any credentials that may have been exposed.