BTCPay backers dangle Bitcoin bounty after Lightning wallet exploit
Supporters of the open‑source BTCPay Server project have put up a substantial Bitcoin bounty in an effort to claw back funds stolen in a recent security incident involving connected Lightning wallets.
They are offering 10% of any Bitcoin successfully recovered, with the payout currently capped at 3 BTC-roughly $190,000 at recent market prices-if all of the stolen coins are returned. The reward is open not only to the attacker but to anyone who can provide actionable information that leads to recovery of the funds.
In a statement published on X on Monday, the BTCPay team framed the bounty as part of a broader push to respond quickly and transparently to the exploit rather than just issuing an apology after the fact.
“We will examine our mistakes, but regret alone will not help affected users or secure the project,” the team wrote. “There is no time to waste. We have to learn, improve, and act quickly.”
The incident centers on a vulnerability that impacted BTCPay installations connected to LND, a popular implementation of the Lightning Network. According to the project, the flaw allowed attackers to obtain LND admin macaroons-high‑privilege credentials that grant extensive control over a Lightning node and the Bitcoin funds associated with it. With those macaroons, an attacker can effectively act as the administrator of the Lightning instance, routing payments, draining channels, or moving coins held in linked wallets.
BTCPay first raised the alarm on Friday, warning users of ongoing attacks and urging immediate defensive action. Administrators were told either to shut down potentially affected servers or to upgrade without delay to a patched release, version 2.4.2. At that time, the team had not yet confirmed the scale of any thefts or fully disclosed the underlying mechanism of the exploit, focusing instead on containment and mitigation.
The subsequent disclosure that funds had indeed been stolen, and that privileged Lightning credentials were compromised, amplified concerns among self‑hosted node operators. For many, BTCPay Server and LND form a critical stack for accepting Bitcoin and Lightning payments in a non‑custodial way-precisely the kind of setup valued by merchants and privacy‑minded users who want to avoid reliance on third‑party processors.
By tying the bounty to the full return of stolen Bitcoin, BTCPay’s backers are trying to create a powerful financial incentive for the attacker to reverse course. Cybercriminals do occasionally negotiate with projects and agree to return funds, especially when tracing tools, on‑chain analysis, and public scrutiny make it increasingly difficult to cash out without exposure. In some cases, attackers later attempt to recast themselves as “security researchers” or “white hats,” though such narratives rarely erase the initial misconduct.
The BTCPay team’s messaging suggests they are prepared for both possibilities: cooperation from the attacker, or none at all. While the bounty is a public invitation to resolve the incident with partial restitution, the project has also emphasized the need to harden its software, revise its security assumptions, and improve operational guidance for users.
For now, BTCPay is urging all operators who rely on LND integration to:
– Immediately upgrade to version 2.4.2 or newer if they have not already.
– Revoke and regenerate Lightning macaroons and any other credentials that may have been exposed.
– Review server access logs and Lightning transaction history for suspicious activity.
– Isolate or shut down any instances that cannot yet be fully audited or brought up to date.
Although BTCPay has not published a detailed, step‑by‑step technical breakdown of the exploit, the core issue-leakage or misuse of admin macaroons-highlights a persistent problem across self‑hosted Bitcoin and Lightning deployments: powerful credentials are often treated as configuration details rather than as secrets that must be tightly controlled. When such credentials are inadvertently exposed through misconfiguration, vulnerable plugins, or transport bugs, attackers can bypass normal security controls entirely.
The incident is likely to reignite discussion about best practices for running Lightning infrastructure in production. Recommended measures include segregating services onto separate machines or containers, limiting the scope of credentials, enforcing strict file and network permissions, and using dedicated hardware or secure modules to safeguard high‑value keys. Regular penetration testing and external code audits are also becoming increasingly important as more real money flows through Lightning‑based systems.
The bounty itself fits into a broader trend in the crypto space, where projects sometimes turn to financial incentives as a last‑ditch effort after a breach. Traditional bug‑bounty programs are meant to encourage responsible disclosure before an exploit occurs, rewarding researchers who report vulnerabilities rather than use them. In contrast, a post‑incident recovery bounty, like the one offered by BTCPay’s backers, is reactive and usually more expensive-but it may still be cheaper than permanently losing user funds or facing severe reputational damage.
For BTCPay Server, the stakes go beyond the immediate financial losses. The project has long positioned itself as a trustworthy, censorship‑resistant alternative to centralized payment processors. Any perception that running BTCPay with Lightning is inherently unsafe could discourage merchants and service providers from adopting it, undermining years of work to make non‑custodial Bitcoin payments accessible.
To counter that risk, the team is likely to pair the technical fix with clearer documentation about secure deployment. That may include revised installation guides, stronger default settings for Lightning integrations, more explicit warnings around admin macaroons and API keys, and possibly tooling that automates some hardening steps for less technical users.
The exploit also underlines the reality that self‑custody comes with responsibility. While managing one’s own keys and infrastructure avoids the pitfalls of centralized custodians, it demands ongoing vigilance. Operators who treat a payment server as “set it and forget it” infrastructure-never updating, never checking logs, never reviewing security advisories-are increasingly exposed as attackers target exactly these neglected nodes.
Going forward, observers will be watching three key threads: whether the attacker engages with the bounty and returns funds; how many users ultimately report losses; and what structural changes BTCPay introduces to prevent similar incidents. Transparent post‑mortems and concrete technical improvements will matter as much as the outcome of the bounty offer.
For now, the message from BTCPay’s backers is clear: they are prepared to pay a significant premium to get stolen Bitcoin back, but they also view this breach as a catalyst to strengthen both their software and the broader operational security culture around self‑hosted Bitcoin and Lightning payments.