Macaroon Credentials

Malicious bots are systematically scanning for exposed Bitcoin payment servers running BTCPay to exploit a timing vulnerability and steal administrative credentials for Lightning Network nodes. This represents an active, ongoing threat to merchant wallets even as developers patch the software, targeting operators who manually restored access after a prior August breach.

• Bots are probing exposed LND password-change endpoints during a brief window after node restart when macaroon authentication is not required.
• BTCPay version 2.4.4, released September 7, closes the restart vulnerability and rotates shared default passwords on older installations.
• Custom deployments and manually exposed infrastructure remain vulnerable; operators must audit proxy rules and migrate behind BTCPay’s managed controls.

• 3 BTC Maximum bounty cap for recovered funds from the August breach, then worth about $190,000
• 2.4.2 Last affected BTCPay version before the August vulnerability was patched in subsequent releases
• Sept. 11 Date a route-control change merged to enable remote access through supported, managed paths

BTCPay Server, a widely adopted open-source Bitcoin payment processor, disclosed that automated systems are actively targeting exposed Lightning nodes to extract master administrative keys. The bots exploit a narrow but critical window that opens after LND (Lightning Network Daemon) restarts while the wallet remains locked. During this interval, the password-change endpoint does not require a macaroon, the cryptographic credential normally required to authorize administrative actions, creating an attack surface for anyone with network access to the interface.

Restart-window vulnerability targets servers with manually exposed LND access

The current bot activity differs from the August vulnerability but follows a similar exploitation pattern. In August, attackers compromised all BTCPay versions before 2.4.2 by obtaining unauthenticated access to LND macaroon files, allowing them to move funds directly from merchant wallets.

This time, the threat vector is more narrowly bound to timing: an attacker must reach the password-change interface immediately after LND restarts, before BTCPay’s internal unlocker process completes.

The risk escalates for operators running older BTCPay installations that used a shared default password across deployments.

An attacker who submits that default password first, changes it, and requests a new administrator macaroon gains control over the entire LND node. BTCPay disabled external LND access in its standard Docker deployment following the August breach, but operators who manually restored that access to support remote operations remain exposed to the bot probing.

BTCPay has not reported any successful takeovers through this newly observed activity, nor has it linked the bots to the threat actors behind the August theft.

Version 2.4.4 hardens default credentials and closes restart-window access

BTCPay released version 2.4.4 on September 7 to address the restart-window vulnerability. New LND wallets now receive unique random passwords instead of a shared default, and older installations using the shared credential are automatically migrated with passwords rotated. The standard reverse proxy now blocks unauthenticated wallet setup and unlock methods at the network perimeter, closing the restart-time opening for any traffic routed through BTCPay’s managed public path.

Those protections apply only to infrastructure deployed according to BTCPay’s standard architecture. Administrators who configured their own reverse proxy or exposed LND directly to the internet can still bypass BTCPay’s controls entirely. The project has urged operators to install 2.4.4 and remove manually exposed LND routes, emphasizing that custom deployments cannot rely on the default hardening measures.

Custom deployments require manual audit as bots continue scanning the network

A route-control change merged on September 11 now provides a supported, managed pathway for remote LND access that keeps the interface disabled by default.

Operators running custom infrastructure must audit their reverse proxy rules immediately to identify any publicly exposed LND or Core Lightning endpoints. Those who need remote access should migrate their configurations behind BTCPay’s official managed controls while automated systems continue searching for reachable nodes.

The urgency reflects the active, ongoing nature of the bot scanning; attackers are not waiting for slower manual patching cycles to complete across the merchant ecosystem.

BTCPay’s security team has not announced a timeline for mandatory updates or forced migration of custom deployments, leaving the responsibility on individual operators to detect their exposure and remediate before bots locate their infrastructure.