Latest Strikes 32 & 33 - August 3rd-16th 2026

• BTCPay Hack
• LND Vulnerability Disclosure
• LDK Release
• Zeus
• RTL Release
• Arks Lightning Update
• Channel Jamming

Hey there Stackers, welcome to Latest Strikes, your “”“weekly”““ report of the latest Lightning-related news. I’ve been having some trouble publishing as regularly as I’d like lately, but hopefully I’ll be able to get things back on track soon™!

As AI-assisted vulnerability research efforts have increased recently, expect a consequent increase in vulnerability reports and security fixes in this newsletter. The last 2 weeks witnessed an actively exploited vulnerability in BTCPay Server, a security update from Zeus, some disclosures, and a few releases.

On a side note the BIP110 fork, about which we provided readers of this newsletter with a few recommendations in the previous issue, proved to largely be a nothing-burger. As expected, hashrate did not largely pivot at the beginning of the mandatory signaling period, resulting in the BIP110 chain being very quickly outpaced by the Bitcoin canonical chain.

§BTCPay Hack

A vulnerability affecting BTCPay Server prior to version 2.4.2 has been detected through its exploitation last week. The vulnerability would allow an unauthenticated remote attacker to access the macaroon credentials of the LND node the BTCPay Server instance connects to, if any. This essentially gives the attacker full control over the Lightning node. Sparrow Wallet developer Craig Raw was the first to discover the attack on his own instance, and quickly responsibly disclosed the issue to the BTCPay team. The root of the vulnerability appears to be an improper 2FA validation in the BTCPay REST API (Greenfield).

For users running an LND-connected BTCPay Server who haven’t done so yet, it is crucial to upgrade to 2.4.2 and rotate LND’s macaroons asap. Other users are still strongly advised to update. Since then, release candidates for version 2.4.3 have been released, with the BTCPay team strongly advising operators to update without waiting for the main release, despite the “release candidate” status.

As mentioned above, the attack has been observed in the wild, with attackers closing channels and sweeping the funds on-chain.

Security Advisory

§LND Vulnerability Disclosure

Bastien Teinturier (ACINQ) responsibly disclosed a vulnerability affecting LND nodes prior to version 0.21.1 (shipped June 2026¹) that could lead to loss of funds. The vulnerability is not believed to have been exploited, but node operators are strongly advised to update.

The issue arises when a channel is cooperatively closed. LND would forget the channel as soon as the close transaction had 1 confirmation, which means that a reorg occurring on that block would leave the node defenceless² against the other party publishing a revoked state to their advantage. The fix is simple: wait for at least 6 confirmations before forgetting a closed channel, which is what the specification already recommends.

§LDK Release

The “MegaScan” releases have brought important security updates to rust-lightning (in v0.2.5, but also back-ported to v0.1.12).

Notable fixes are an HTLC misattribution that could lead to failing back an HTLC while it was actually still live, ultimately leading to loss of funds; and multiple potential DoS vectors through remotely-triggered node panic.

§Zeus

Zeus’ infrastructure (Lightning node, LSP, Zeus Pay, etc.) was temporarily taken offline following a security incident. Like the outage affecting Boltz, the self-custodial nature of Zeus’ offering means user funds were never at risk. Service has been brought back up gradually over the last few days.

The Zeus team has also shared a post-mortem, indicating that the root cause was the BTCPay vulnerability mentioned earlier, which allowed an attacker to gain access to the admin macaroon of an LND node that also serves as part of Zeus’ LSP offering. The BTCPay instance was used to “provid[e] fiat currency exchange rates and [accept] donations”.

See the Security Update for a more detailed timeline.

§RTL Release

Version https://github.com/Ride-The-Lightning/RTL/releases/tag/v0.15.10 of “Ride The Lightning” (RTL) “tightens how RTL handles and exposes authentication material, both in its own API responses and in the node log files users routinely share when asking for help”. Basically, it addresses the same kind of attack vectors that led to the BTCPay hack we discussed above. Operators are strongly advised to update.

§Arks Lightning Update

On the Lightning side, the v0.5.0 and v0.6.0 of bark (Second’s Ark implementation) released 2 weeks ago brought a few interesting features and fixes, notably:

• a breaking change where it is now checked whether the preimage of an HTLC is 32 bytes. Clients must update to remain compatible for Lightning features;
• the ability for Lightning receives to land on an external Ark address, without the forwarder even gaining custody of the funds, which enables use cases such as “non-custodial” Lightning Address servers (although plain self-custody remains guaranteed only after a refresh);
• a fix to a race condition where an attacker would generate an invoice from their bark client with a very short min_cltv_delta (quick HTLC expiry), pay it using their node, and be able to claim both the refund on their node (at HTLC expiry) and the VTXO on Ark.

Arkade shipped the RFQ Protocol (Request For Quote), which allows parties to negotiate quotes over Nostr relays. An implication of this protocol is performing Arkade <> Lightning swaps without relying on a centralized coordinator. The other underlying mechanism is intents, which is basically how users can express their conditions and initiate the swap. A solver can then pick up the swap if they deem the quote reasonable. Note that since this is still early, right now there is only one pinned solver for Lightning swaps. In the future, multiple solvers should be available, with Nostr relays serving as “bulletin boards” for quotes. For (oh my! time flies!) older readers of this newsletter, this may remind you of the CivKit protocol.

§Channel Jamming

Antoine Ariard proposed a DLC-like mechanism to deter channel jamming by making the fee paid for the routing of an HTLC (or PTLC) proportional to how long it was held in a channel. Like DLCs, it uses Contract Execution Transactions (CETs) and adaptor signatures to build and enforce a contract; but unlike DLCs it doesn’t rely on signatures provided by a third-party oracle. Instead, the 2 parties can exchange adaptor secrets on every tick of an agreed-upon clock, which unlocks the spending of a CET; while challenge-based transactions are available for 2-step unilateral exits on both sides.

Let’s consider a channel between Alice and Bob. Alice wants to forward an HTLC through this channel. Alice and Bob agree on a “contract” that specifies the fee paid by Bob to Alice based on how much time has elapsed.

1. Alice and Bob split the maximum retention time of the HTLC into smaller periods. For example, if the HTLC expires in 1 hour, they can split it into 6 10-minute chunks³.
2. For each chunk, they agree on the amount of the “withhold fee” that Bob pays Alice. Of course, to incentivize quick settlement of the payment, this fee increases as time passes. For example:

3. Each of these possibilities is represented by its own Contract Execution Transaction (CET), which is a presigned transaction that commits to the withhold fee paid by Bob. The signatures exchanged by Alice and Bob are adaptor signatures, which means they need an additional secret to be “decrypted” and properly sign the transaction. At first, only Alice (resp. Bob) knows the secret for each of her (resp. his) adaptor signatures.
4. When each period ends, Alice and Bob exchange their adaptor secrets for the next period. Both parties are incentivized to take part in this exchange. Bob sends his secret first, then Alice responds with hers.

When at some point Bob reveals the preimage to Alice, Alice settles the HTLC off-chain using the last CET she has Bob’s “adapted” signature for. For example, if she receives the preimage after 35 minutes and Bob played along, she keeps a 20 sats withhold fee, which is effectively paid by Bob.

If any of the parties stops responding during the process, the other can claim the whole withhold fee using a 2-step on-chain transaction, with a timelock allowing the other party to dispute this, a bit like channel force-close transactions work.

StackerNews Discussion

https://stacker.news/items/1552184