BTCPay emergency patch exposes merchant-side Bitcoin security risk

An emergency update has been rolled out by BTCPay Server, the open-source software merchants use to accept Bitcoin, due to a vulnerability being exploited to potentially steal funds from users.

As identified in GitHub pull request #7491, this vulnerability enables cybercriminals to circumvent the TOTP two-factor security mechanism through BTCPay’s Greenfield API Basic Authentication. The reason for the vulnerability lies in the fact that the authentication mechanism checked whether valid FIDO2 credentials were registered rather than actually checking whether the two-factor system was even enabled. Thus, the accounts secured with a TOTP authenticator application could access the API using only their email and credentials.

It is important to note that the vulnerability exists within the application layer of BTCPay, not in the Bitcoin (BTC) protocol.

BTCPay has launched version 2.4.2 of its software on August 7 while also advising users to make sure they have updated to the version 2.6.10 of NBXplorer. The upgraded software addresses a “critical vulnerability” that is currently being exploited.

A market that shrugged at the payments scare

Despite the ongoing security concern plaguing the payment system, Bitcoin’s market price and valuation are relatively stable. Bitcoin is trading at about $64,889, which is just a 0.82% increase from the previous day, while its $1.3 trillion market cap has seen a rise of only 0.79%. Even though trading activity has been more active with the 24-hour volume increasing 20.98%, the fairly stable price and market cap indicate that the incident has not yet had an impact on Bitcoin’s overall market valuation.

The subdued response is understandable. The BTCPay vulnerability affects only individual merchants and operators, not Bitcoin’s consensus rules or cryptography.

However, that does not mean it is insignificant. BTCPay creates a link between the Bitcoin network and the payment systems of businesses issuing invoices, receiving payments and managing the wallets. Therefore, in case of an attack on the operator account, it becomes possible to cause real monetary losses despite the proper functioning of the Bitcoin blockchain.

What BTCPay told operators to do

The immediate solution to this problem is simple: upgrade BTCPay Server to version 2.4.2 and, for integrators, upgrade NBXplorer to version 2.6.10.

According to BTCPay, it is better to use application programming interface (API) keys instead of Basic Authentication because permissions can be limited more effectively. The new patch has also introduced changes to the authentication process so that it will be able to check whether 2FA is really active, thereby closing the gap which enabled TOTP-protected accounts to avoid the second authentication level.

Since BTCPay is self-hosted, operators cannot depend on a central provider to implement the patch for them.

A third strike for Bitcoin’s payment plumbing

BTCPay’s announcement comes after a tumultuous week for Bitcoin’s payment system. Cryptopolitan had reported earlier that ZEUS, the provider of a Lightning wallet, had rendered its payment infrastructure inactive because of a problem that occurred involving the security of the system, while other Lightning service providers also got affected.

The occurrences do not indicate that the Bitcoin payment protocols are failing in any way. They do show, however, how much additional security risk is introduced by the software built around the blockchain.

A 2024 study by researchers from Northeastern University and TU Delft used formal modeling to identify security problems in Lightning’s single-hop payment protocol, including a new “Payout Race” attack.

A separate 2026 study examined balance-discovery attacks, finding that attackers can infer information about Lightning channel balances. Its proposed mitigation reduced information gain by as much as 62% in simulations.

Both the studies reveal a more significant truth: the security of Bitcoin does not merely depend on the blockchain. Wallets, APIs, payment processors, as well as the Lightning infrastructure all introduce additional points of vulnerabilities.

Not BTCPay’s first critical bug

BTCPay has previously encountered serious vulnerabilities. In January 2023, it reported about CVE-2022-32984, a critical information leak that affected BTCPay’s versions 1.3.0, 1.4.0 and 1.5.3.

The flaw has the potential to leak sensitive store details via publicly available Point of Sale applications, possibly exposing an xpub and Lightning credentials tied to an external node. BTCPay resolved this problem in version 1.5.4 and later rewarded researcher Antoine Poinsot with a bounty of $5,000.

The difference here is clear: the 2023 attack was an information leak while the recent vulnerability has to do with authentication issues that circumvent TOTP security through the Greenfield API.

Why merchants have more to lose now

Things are heating up as Bitcoin becomes increasingly valuable for payments. Research from River published in February 2026 noted average Bitcoin usage by merchants increased by 74% in 2025 alone while Lightning usage increased by 300% and went over $1 billion in monthly volume.

The surrounding infrastructure is also significant. BuiltWith has detected 248 sites that use BTCPay Server, which include 74 active ones, although these numbers don’t include private or other undetectable installations.

Additionally, the latest snapshot by 1ML shows there are 6,280 Lightning nodes, 21,221 channels, and the current network capacity of 2,818.49 BTC.

That scale makes vulnerabilities in the surrounding infrastructure all the more severe, even if the base layer of Bitcoin hasn’t been affected in any way.

The takeaway from BTCPay does not suggest that Bitcoin itself is flawed. Instead, it indicates that businesses built on Bitcoin inherit a broader security burden. The blockchain may still be functioning, but the applications used by merchants may become a point of failure.

For BTCPay operators, the priority is simple: upgrade to version 2.4.2, evaluate authentication logs and access logs for signs of compromise, and to use specific API keys instead of Basic Authentication when possible.

The smartest crypto minds already read our newsletter. Want in? Join them.