Welcome to Latest Strikes, your (bi fluid) weekly report of the latest Lightning-related news. As a direct result of the ongoing AI-assisted vulnerability research across the Bitcoin open source ecosystem, the last 2 weeks have seen releases from 3 Lightning implementations, with 2 of them strongly suggesting operators upgrade. As you’ll see, ping pong (or table tennis) played a huge part. We’ve also seen releases in a variety of Lightning software, as well as some interesting research on threshold custody in Lightning.

Core Lightning Release

Core Lightning v26.06.7 was released, with an unusual twist. Since the release contains fixes for a lot of vulnerabilities, the team has elected to provide only binaries (and no source code) for the duration of a 2-week embargo. The goal is to prevent attackers from easily learning the vulnerability by scanning the release’s diff while the network gradually upgrades¹. However, a side-effect is that node operators themselves cannot see the code they are strongly encouraged to run on their machine, with money at stake.

The Core Lightning team hence proposes 2 paths for operators:

1. Upgrade asap. This is clearly the preferred choice. We obviously don’t know the full extent of the vulnerabilities yet, but the release notes contain the list of persons who submitted reports, and it’s 16 “entities” long.
2. Restart in “offline” mode. For operators reluctant to update before they’ve seen the source code, or simply unable to do so, they should restart their node with the --offline flag. This turns off all the port bindings, meaning your node becomes basically unreachable, while still continuously watching the chain to detect channel force closes, and punish any cheating attempts.

While suboptimal, I think Core Lightning’s 2-week embargo period, after which the source code will be released, is defensible. The decision whether to upgrade or not is ultimately a personal choice, highly dependent on an operator’s specific context, but I’d summarize it as:

• if your node only has mild to sporadic usage and a 2-week inactivity period isn’t too bad, and if you don’t mind the potential force close from peers in the meantime², then you can safely use the “offline” mode;
• else, I’d strongly suggest updating asap, if not already done.

X Announcement

Core Lightning Vulnerability Disclosure

Erick Cestari disclosed a vulnerability in Core Lightning that would allow any remote attacker to crash a node. The vulnerability has been fixed in version 25.09 of Core Lightning, released in September 2025.

The issue lay in the absence of a backpressure mechanism for certain peer messages in Core Lightning, notably the pong message. This message is always generated as a response to a ping message³, sent by a peer on a TCP connection. This message exchange primarily serves as a way to keep the connection open, but is also used to fabricate traffic patterns and weaken packet and timing analyses, by having the ping specify the length of the pong response.

By sending many ping requesting pongs with the maximal allowed size (65531 bytes) and never reading the responses, an attacker is able to saturate the connection. pong messages quickly accumulate in the Core Lightning node’s sending queue, unbounded. Memory usage grows until it reaches the system’s limit and the process is killed. Note that the attack works in a similar manner with the query_channel_range message.

This attack only works with the limited number of message kinds that the connectd daemon processes itself, without deferring to another subprocess. Other messages already had backpressure built-in through a “hold and wait” gate. The fix was hence simply to apply the same gate to affected messages (ping and query_channel_range), effectively now bounding the sending queue to at most 1 pong message per connection. Until the peer reads the pong, no other ping message they send will be treated.

Erick discovered the vulnerability while testing his own implementation of Bolt 8 against other implementations in a regtest environment. He privately disclosed it to Rusty Russell, and the fix landed in the codebase a week later.

Blog Post

Eclair Release

Version 0.14.2 was released, containing several bug fixes. Node operators are strongly advised to update.

Fixes

This release contains:

• multiple fixes relating to the handling of peer connections and messages, including rate-limiting the query_channel_range (one of the message vectors in the above Core Lightning vulnerability), which is cheap for an attacker to send but can be costly for the responding node;
• a fix to a potential mismatch of in-flight HTLCs after a node restart, which could let an attacker trigger force closes remotely;
• multiple fixes with on-chain transactions (fee-bumping, retries);
• many, many more fixes.

Changes

Noteworthy changes:

• support for fulfillment payload relay and authentication, enabling payment proof for spontaneous payments;
• changes in the configuration of onion messages relay policies.

LND Releases

We’ve got 2 LND releases in the past weeks: version 0.21.2 and the first release candidate for 0.21.3.

Fixes

Like Eclair, these releases contain fixes against peer connection and message abuse:

• v0.21.2 bounds the memory used during channel sync, as a malicious peer responding to LND’s query_channel_range message could make the node buffer an arbitrary and unpredictable amount of short channel IDs
• v0.21.3 now rate limits incoming ping messages and bounds the size of the outgoing pong messages queue to protect against remotely-triggered resource exhaustion.

As you can see, those are the exact 2 message types at the root of the Core Lightning vulnerability we discussed above. Given the vulnerability disclosure timeline, it begs the question of whether the bugs were also discovered in Eclair and LND by Erick at the same time, or if the findings gradually circulated among Lightning developers, or if the discoveries themselves are unrelated.

Version 0.21.2 also fixes several database migration bugs. Version 0.21.3 addresses a bug that could prevent a node from opening new channels (including those already in the process of opening when the bug was triggered) until it was restarted; as well as multiple HTLC and closing transaction handling bugs.

The above summary is of course not exhaustive, and node operators are advised to read the full changelogs (21.2, 21.3) for more details.

StackerNews Discussion

BTCPay Update

In the aftermath of the hack and emergency release of version 2.4.2, v2.4.3 of BTCPay Server has been released. It is also a security release, and operators of a BTCPay Server instance should update promptly.

X Announcement

Security Notices

Two breach notices were issued by Lightning companies Coinos and Pocket. In both cases, attackers obtained access to internal production databases.

• For Pocket, the attackers were able to access email addresses and support conversations, as well as “identity documents, source of funds records, postal addresses and, for some, the bitcoin address used for their transaction” for a subset of users. Users impacted by the latter have been contacted personally on August 31st. No email from Pocket means “only” your email address and support conversations were accessed.
• For Coinos, as founder Adam Soltys indicates, the attacker managed to access NWC secrets. All NWC connections were hence revoked, and users should create a new one if they want to continue using NWC with Coinos.

Enabling Threshold Custody for the Lightning Network

Paul Gerhart, Nadav Kohen, Jesse Posner and Matias Furszyfer published Iceberg, a novel nested threshold multi-signature scheme, enabling threshold custody for Lightning Network nodes.

Currently, a Lightning node relies on a single signer (a single main private key), whose theft or loss can result in complete loss of funds. While multisignature schemes have long existed for on-chain Bitcoin, allowing holders to distribute the access to the funds across multiple keys with highly customizable threshold rules, porting this to Lightning has proven quite difficult. On legacy (non-Taproot) channels, this would have required significant changes to the Lightning protocol. On Taproot channels, a standing issue was that each signing session required committing to the specific set of signers that would later sign, and part of this signer set could then be offline when signing time had come.

The Iceberg scheme manages to overcome this difficulty (essentially by making the group’s nonce independent of who is online) for Taproot channels. Crucially, a Lightning node managed by a k-of-N multisig is indistinguishable from a “regular” Lightning node. This means “multisig” Lightning nodes can join the existing network without any change to the larger protocol. They may already be among us.

When it comes to security and availability, the Iceberg scheme is a little different from on-chain k-of-N mechanisms. It is best understood as threshold base, where a group of node operators can adjust the system’s parameters depending on their goals. For a given threshold t:

Property	Value
Corruptions tolerated	t − 1
Online members needed to sign	2t − 1
Minimum group size N	3t − 2

“Corruptions tolerated” here is the number of group members (signers) an attacker can fully control without being able to forge a signature or steal the channel funds. An intuitive way to look at this is that the minimum group size is derived from the corruption tolerance and the minimal signing quorum: when the corruption tolerance is hit, at least an uncorrupted minimal signing quorum must remain to be able to sign. Hence: Minimum group size = Online members needed to sign + Corruptions tolerated.

Say you want this number to be 1, i.e. the first key compromised doesn’t lend access to all the funds (but the second will, and the setup should hence be rotated promptly). Then you need t to be 2, and the rest follows.

Property	Value (t = 2)	Value (t = 3)	Value (t = 4)
Corruptions tolerated	1	2	3
Online members needed to sign	3	5	7
Minimum group size N	4	7	10

As you can see, every time we increase the corruption tolerance by 1, the cost is that the minimum group size increases by 3. But for a (t, N) pair of (2,4) (one corruption tolerated), things are still manageable and the node can tolerate the compromise of one signer, which if the others are properly segregated can give enough time for the operators to move the funds to a safe setup. Interestingly, such a setup also shows little performance downgrade compared to a “regular” node, based on tests conducted by the authors.

I think this is very important news, and a very interesting scheme. Of course, for individual node runners this potentially means increased security (like an on-chain multisig does), but Iceberg really shines when it comes to organizations’ nodes, such as companies, associations or more informal projects. The node’s keys can be distributed across relevant stakeholders, improving operational security and enforcing governance.

StackerNews Discussion - Initial Paper | StackerNews Discussion - Iceberg Post

Alby Hub Release

Version 1.24.0 (codename: Julian Assange) of Alby Hub was released, bringing many bug fixes and enhancements. A couple stood out to me:

• a path traversal bug that could potentially allow an attacker to write files in arbitrary locations, by having the user recover using a malicious backup file;
• a sanity check of LSP opening fees for Just-in-Time channels, capping them to prevent a malicious LSP from charging absurd fees to inattentive users.

Quick Strikes

• ademan proposed a mechanism to make small-value just-in-time channels in lArk (Lightning Ark, a modified Ark protocol optimized to accommodate LSP operations) less trust-dependent by having the ASP preallocate VTXOs that can be “slashed” by users if LSP and ASP misbehave and collude to misattribute funds;
• Rob released silentpayments.net, where users can claim their address (e.g. rob@silentpayments.net), which gets resolved at the DNS level as a silent payment address and/or a Lightning Offer. The nice twist is that at the same time he published an open source package that lets users check in real time that the DNS record indeed points to the payment code(s) they specified.

---

That’s it for today! Thank you so much for reading this far, and until next week!

Footnotes

1. See Zero Day Clock, which measures the time between public disclosure and exploitation of a CVE. ↩

2. After all, from their point of view, your node is offline. ↩

3. See Bolt 1 for more details. ↩