payment processor

Bitcoin payment processor BTCPay Server is contending with automated attacks targeting administrative access to Lightning Network nodes, months after a critical vulnerability exposed merchant funds. The fresh threat underscores the security risks facing self-hosted payment infrastructure operators who manually expose backend systems.

• Automated bots are probing exposed LND nodes to exploit a restart-window vulnerability that bypasses macaroon credential requirements.
• BTCPay version 2.4.4, released Sept. 7, implements unique random passwords for new wallets and blocks unauthenticated setup methods by default.
• Administrators with custom reverse proxy configurations remain vulnerable despite patches, requiring manual audit and migration to supported access controls.

• Aug. 7 Date BTCPay disclosed critical vulnerability affecting all versions before 2.4.2
• 3 BTC Maximum bounty cap for recovered bitcoin from August theft, worth approximately $190,000 at the time
• Sept. 7 Release date of BTCPay version 2.4.4 addressing the restart-window attack vector
• Sept. 11 Date a route-control change merged enabling supported remote access with disabled defaults

Current Attack Campaign Targets Manually Exposed Infrastructure

BTCPay Server has detected a sustained campaign of automated systems probing exposed Lightning Network nodes seeking administrative control. The reconnaissance activity targets servers where operators manually restored external access to LND nodes after BTCPay disabled it by default in response to an August vulnerability. Attackers appear to be repeatedly calling an LND password-change endpoint, attempting to exploit a brief security window that opens when LND restarts with its wallet still locked.

The timing of this campaign is significant, as it follows BTCPay’s decision to disable remote access to LND in its standard Docker deployment by default. This architectural change protected the majority of users running standard configurations, but created an unintended consequence: operators who needed remote access and manually reconfigured their systems became conspicuous targets. The attacker reconnaissance suggests threat actors are systematically searching for these manually exposed nodes, likely using port scanning and LND-specific service fingerprinting techniques.

The Restart-Window Vulnerability Underlying The New Attack Vector

The newly observed attack path exploits a temporary condition in LND’s initialization sequence. During the interval after LND restarts but before BTCPay’s internal wallet unlocker activates, the password-change endpoint does not require a macaroon, the credential type LND ordinarily uses to authorize administrative actions. Older BTCPay deployments compounded this risk by configuring all LND wallets with the same default password, creating a single point of failure across multiple merchant deployments.

An attacker reaching the exposed endpoint during this window could potentially submit the shared default password first, modify it unilaterally, and request an administrator macaroon that grants full control over the node. This mechanism differs from the vulnerability exploited in August, which allowed unauthenticated access to macaroon files themselves, but could yield the same outcome: complete node compromise and potential fund theft.

The restart-window vulnerability represents a class of attack that security researchers call “initialization race conditions,” where protective mechanisms have not yet activated after a system boots. These attacks are particularly challenging to defend against because they require precise timing but can be automated at scale through retry logic. Threat actors can trigger repeated LND restarts through denial-of-service techniques or simply wait for legitimate maintenance windows when administrators reboot systems.

BTCPay has not reported any successful takeover attempts through the newly detected activity.

August Breach And The Summer Of Merchant Fund Losses

The current probing campaign reflects ongoing consequences from an earlier critical flaw. On Aug. 7, BTCPay acknowledged that attackers had exploited a vulnerability in all versions before 2.4.2, enabling unauthenticated access to LND macaroon files. Threat actors used those stolen credentials to move merchant funds, triggering an urgent response that included a recovery bounty equal to 10% of recovered bitcoin, capped at 3 BTC, then valued around $190,000.

The August vulnerability represented a confluence of security failures. The macaroon files, which serve as long-lived authorization tokens, were accessible over the network without authentication due to insufficient default access controls. Additionally, many deployments lacked proper network segmentation, leaving the LND interface reachable from untrusted networks. The incident highlighted how self-hosted cryptocurrency infrastructure, while offering advantages in terms of privacy and custody control, creates operational security burdens that many merchants were unprepared to manage.

Following the August disclosure, BTCPay disabled external access to LND in its standard Docker deployment, preventing unauthenticated operators from exposing the interface to the internet by default. The project simultaneously enlisted exchanges, blockchain analysis firms, and law enforcement to track the stolen funds. That protective measure proved insufficient for operators who manually reconfigured their infrastructure to restore remote access, leaving them exposed to the restart-window attack now under active reconnaissance.

Patched Defaults And The Persistent Custom Deployment Risk

BTCPay’s version 2.4.4, released Sept. 7, implements multiple hardening measures. New LND wallets now receive unique random passwords instead of a shared default, while existing installations using the common credential are automatically migrated and have their passwords rotated. The standard reverse proxy bundled with BTCPay now blocks unauthenticated wallet setup and unlock methods, closing the restart-window opening through its managed network path.

These protections apply only to infrastructure using BTCPay’s standard configuration. Administrators who created custom reverse proxies or independently exposed LND publicly can still circumvent the built-in controls, remaining vulnerable to the automated probing detected in recent weeks. This limitation reflects a broader challenge in open-source security: developers can provide secure defaults and recommended architectures, but cannot enforce their use across diverse deployment scenarios.

A route-control change merged Sept. 11 provides a supported mechanism for remote access while keeping LND and Core Lightning interfaces disabled by default. This approach follows the principle of “secure by default” while acknowledging that some operators require remote management capabilities. Organizations needing to expose LND can now do so through BTCPay’s own reverse proxy, which enforces authentication and rate limiting before requests reach the backend service.

BTCPay has urged all administrators to upgrade to version 2.4.4 and remove manually exposed LND routes.

Implications For Self-Hosted Payment Infrastructure

The successive vulnerabilities and ongoing attacks underscore a critical tension in the Bitcoin payment ecosystem. While self-hosted solutions like BTCPay provide merchants with direct custody of funds and eliminate third-party payment processor intermediaries, they shift security responsibility to organizations that may lack specialized infrastructure expertise. The distinction between “default secure” configurations and “optionally insecure” custom deployments has become a first-class security problem.

Industry observers note that this pattern reflects challenges across the self-custody ecosystem generally. Hardware wallets, software wallets, and payment processors all face similar scenarios where advanced users require capabilities that conflict with security-by-default principles. The tension becomes acute when automated attackers can identify and target the less secure configurations at scale, as appears to be happening with exposed LND nodes.

Operators deploying custom infrastructure configurations must now audit their reverse proxy rules and migrate any remote connections behind BTCPay’s managed controls, as automated systems continue scanning for reachable nodes. The project’s inability to secure independently configured deployments leaves custom operators as the immediate concern, requiring manual intervention to prevent the restart-window vulnerability from being exploited at scale.