Automated bots are actively probing exposed Bitcoin payment servers for a route into administrative control, BTCPay Server has warned. The targets are merchants running Lightning nodes with manually restored external access, and the prize is the credential that controls an LND node and the funds behind it.
The activity follows a separate critical vulnerability that attackers exploited a month ago to obtain credentials protecting LND nodes and drain merchant wallets. BTCPay responded by disabling external access to LND, a widely used implementation of Bitcoin’s Lightning Network, in its standard Docker deployment. That closed the public path. The new campaign targets the servers where operators opened it again by hand.
A window after every restart
The latest mechanism differs from the August bug but could lead to a similar outcome: an attacker obtaining credentials that can control an LND node. BTCPay says the opening appears during a short interval after LND restarts, while its wallet remains locked. During that period, the targeted password-change method does not require a macaroon, the credential LND normally uses to authorize administrative actions.
In plain terms, the macaroon is the key that separates a read-only observer from someone who can move channels and funds. If the password-change endpoint accepts calls without it, a bot that reaches the node during the restart window can reset the credential and lock out the operator. The bots repeat their calls against the endpoint, waiting for a server to restart at the wrong moment. A restart is not a rare event: node operators restart LND for upgrades, configuration changes, and crash recovery, so the vulnerable interval recurs on a schedule the attacker does not control but can wait for.
The fix and who is still exposed
A route-control change merged on September 11 provides a supported option for remote access while keeping LND and Core Lightning interfaces disabled by default. That leaves custom deployments as the immediate concern. Operators using them must audit their proxy rules and migrate remote connections behind BTCPay’s managed controls while automated systems keep searching for reachable nodes.
The project’s advice is blunt: if you exposed LND manually, close it. Version 2.4.4 closes the standard public path, so the risk is limited to deployments that bypassed the default configuration. BTCPay is the most popular self-hosted Bitcoin payment processor, used by merchants who want no third party between them and their coins, which is exactly why its operators tend to customize. The installed base includes everything from single-node hobby setups to payment processors running dozens of stores, and the customization culture means no one knows how many exposed proxies exist.
A month of Lightning security failures
The BTCPay warning is the third Lightning-adjacent security story in two weeks. On September 13, CryptoSlate reported critical bugs in Bitcoin Core Lightning’s Docker setup that left node operators exposed even after they saw updated version numbers, a display mismatch that made patched systems look protected when they were not. The same day, Lightning Dev Kit released v0.2.6, addressing small splice-related fund losses and a payment-handling flaw that could prevent saved channel state from loading on restart.
The pattern across all three is the same: the money is not stolen from the Bitcoin blockchain, which remains unbroken, but from the software layers around it. Lightning nodes hold hot wallets by design, and their administrative interfaces are the shortest path to those funds. A splice bug leaks small amounts channel by channel. A broken state loader freezes funds in place. An exposed admin endpoint can take everything at once. The severity differs, but the direction of attack is identical.
What merchants should do now
For anyone running BTCPay with Lightning, the checklist is short. Update to 2.4.4 or later. Confirm that LND and Core Lightning external interfaces are disabled in the default route controls. If remote access is genuinely needed, use the route-control option merged on September 11 rather than manual proxy rules. Restart LND during a supervised window, since the unauthenticated interval sits right after a restart while the wallet is still locked.
Operators who already ran the August incident know the stakes. That attack ended with drained merchant wallets and a forced change to the default Docker deployment. This one has not produced confirmed losses yet, but the bots are not probing for fun. They are waiting for a restart window on a server whose operator thought the default lockdown did not apply to them.
Self-custody trades one risk for another
The broader lesson keeps repeating itself in Bitcoin infrastructure. Self-custody removes the counterparty risk of an exchange and replaces it with operational risk that lands entirely on the operator. A merchant who holds coins on Coinbase worries about the exchange’s solvency. A merchant running BTCPay worries about their own server, their own firewall rules, and their own upgrade discipline. The August attack showed which failure mode hurts faster: when the credential layer breaks, funds are gone before the operator notices anything.
Bots scanning the internet for exposed Lightning endpoints do not care whether the server belongs to a coffee shop or a brokerage. If the macaroon check is missing for ten minutes, that is enough. The economics favor the attacker, since a single scan costs nothing and one exposed node can hold months of merchant revenue.
The project has now shipped two fixes in a month and changed its defaults once. What remains uncertain is how many operators read the advisory before the bots find them. The history of payment server security, in Bitcoin and outside it, suggests the answer is: not enough of them.