BTCPay Server Warns a Live Attack Can Drain Funds. The Exploit Slips Past a Defense Users Trust

A security warning from BTCPay Server is demanding immediate attention from merchants who use the software to accept bitcoin.

The project says attackers are actively exploiting a critical vulnerability that can lead to lost funds.

The emergency fix is version 2.4.2.

What makes this flaw especially dangerous is the protection it managed to evade.

An affected account could require a time-based one-time password, the familiar six-digit code generated by an authenticator app, and still leave a separate door open through BTCPay Server’s Greenfield API.

The authenticator code itself was not cracked.

The vulnerable login path simply failed to demand it.

There is a critical vulnerability being actively exploited on BTCPay Server, which can result in the loss of funds.

Please update your BTCPayServer to 2.4.2 by going to Admin Dashboard -> Server -> Maintenance -> Update & verify the 2.4.2 version string in the footer.

If you…

— BTCPay Server (@BtcpayServer) August 7, 2026

BTCPay Server’s official 2.4.2 release notice describes the vulnerability as critical and actively exploited. The project is urging every operator to update as quickly as possible rather than waiting for a normal maintenance window, even if the server has shown no obvious sign of compromise.

The release closes a two-factor authentication bypass involving Greenfield Basic authentication. It also changes Greenfield Basic authentication so that it is disabled by default five minutes after a new account is created.

BTCPay says integrators that run NBXplorer separately should update that component to version 2.6.10 as well.

The warning is unusually direct for an open-source release note: an exposed server can lose money, and exploitation is already happening.

No public victim count or confirmed loss total was included in the notice. Claims circulating beyond that should be treated cautiously until the project or affected operators provide evidence.

The release is a security-only build, giving operators a narrow change set to evaluate when speed matters more than waiting for a broader upgrade.

BTCPay Server is popular precisely because it lets merchants process bitcoin payments without handing custody and transaction data to a traditional payment company.

A business can run the software on its own infrastructure, connect it to its own wallet and Lightning node, and receive payments without a processor standing between buyer and seller.

That independence is powerful.

It also means the person operating the server owns the security response when the application itself needs an emergency patch.

The code-level explanation in BTCPay Server’s security fix shows why the problem could be easy to misunderstand. Accounts protected only by an authenticator app could call the full Greenfield API with an email address and password, giving the API session far more authority than the same credentials received through the dashboard.

Instead of stopping the login and requiring the second factor, the API issued an unrestricted permission claim.

The normal web interface handled the same account correctly and forced the user to complete two-factor authentication. The gap existed in the Basic authentication route used by the API.

That distinction matters because a merchant who tested the dashboard could see two-factor authentication working exactly as expected and reasonably believe the account was protected everywhere.

Users with a registered FIDO2 security key were already blocked from this path, according to the project’s technical analysis. The exposed group was made up of users whose two-factor protection relied on TOTP without an accompanying FIDO2 credential.

Rate limiting still stood in the way of rapid password guessing. But a stolen, reused or otherwise compromised password could become far more valuable when an attacker did not have to supply the authenticator code.

That is how a flaw in an authentication decision can turn into a funds-loss event without defeating the cryptography behind bitcoin or the authenticator app.

The fix replaces the incomplete credential check with BTCPay Server’s standard test for whether two-factor authentication is enabled on the account.

THE BLOCK: @BtcpayServer disclosed that a critical vulnerability is "being actively exploited", and urged users to update their servers to version 2.4.2, according to its official X account on Friday. pic.twitter.com/i5nZJNbP0K

— The Block (@TheBlockCo) August 7, 2026

A second change merged into version 2.4.2 sharply limits the exposed authentication method. Greenfield Basic authentication now turns off by default five minutes after account creation, replacing a standing attack surface with a brief setup window that operators must consciously reopen.

That short window remains so an automated installation can create its initial API key. Operators who truly need Basic authentication can deliberately enable it again, but leaving the method available indefinitely is no longer the default.

The project says the method was rarely used. The API-key route remains available for integrations that need long-term programmatic access.

That is good security design after a bypass: fix the faulty check, then reduce how long the risky path is exposed in the first place.

Existing installations receive that safer default as part of the same emergency update, without requiring merchants to redesign their payment setup.

For operators, the immediate response is simple.

Open the BTCPay Server administration dashboard, go to Server Settings, choose Maintenance and run the update. When the server returns, confirm that 2.4.2 appears in the page footer.

BTCPay Server’s maintenance documentation also provides the command-line route for Docker deployments: enter the BTCPay Server Docker directory and run the project’s update command as the administrator.

Updating is the first move, not the last one.

Because the bypass depended on a valid password, the incident is also a reminder that two-factor authentication works best as one layer in a larger defense. A unique password, a hardware security key where supported and tightly scoped API keys can keep one stolen credential from becoming total account access.

Internet-facing BTCPay instances should expose only the services they need. Integrations deserve the smallest permissions that let them function, and credentials that no longer serve a purpose should be removed rather than left dormant.

An operator should review account activity, API keys, authorized applications, withdrawal or payout activity, and server logs for anything that does not belong. Passwords that were reused elsewhere should be changed, and any credentials stored in an integration should be rotated if compromise is suspected.

Merchants should also verify that expected wallet balances and recent settlements match their own records. A clean-looking dashboard alone cannot prove that no API access occurred before the patch.

If a separate NBXplorer instance is part of the deployment, it needs the companion update named in the release.

Self-custody removes a trusted intermediary.

It does not remove software risk, exposed credentials or the need to patch a server when maintainers raise the alarm.

BTCPay Server’s warning leaves no room for delay: version 2.4.2 is not a feature upgrade to schedule later.

It is the line between an authentication path attackers can exploit and one that finally enforces the defense users thought they already had.

Join the conversation!

We have no tolerance for comments containing violence, racism, profanity, vulgarity, doxing, or discourteous behavior. If a comment is spam, instead of replying to it please click the icon below and to the right of that comment. Thank you for partnering with us to maintain fruitful conversation.