Core Lightning flaw keeps nodes crashing after upgrade until stored record is removed
In brief
- Core Lightning v25.02 through v26.04 are affected, per Nishant Bansal's October 24 disclosure.
- A channel announcement naming one node as both endpoints aborted gossipd and took down the node.
- The v26.04.1 fix, shipped April 25, checks only incoming announcements.
- Operators must manually remove a malicious record already saved in gossip_store.
- Maintainers strongly recommend v26.06.9, the latest release, issued October 7.
What triggered the crash
Channel announcements tell nodes about connections in the Lightning routing graph. In this case, per Bansal's disclosure as reported by CryptoSlate, an announcement named the same previously unknown node as both endpoints. Vulnerable versions (v25.02 through v26.04) accepted it and wrote it to the on-disk gossip_store before loading it into the routing graph.
That's where it broke. The graph tried to insert the same node twice, a duplicate safeguard aborted gossipd, and Core Lightning treated that failure as fatal to the whole node.
Bitcoin Optech highlighted the issue on October 30 and noted that releases before v25.02 could accept and relay these announcements without crashing. So an attacker didn't need a direct connection to every vulnerable node.
Why upgrading isn't enough
Core Lightning merged PR #9082 on April 24 and shipped the fix in v26.04.1 on April 25. The patch checks endpoint ordering before accepting an announcement, requiring the first node ID to be strictly less than the second (which also rejects equal IDs).
It doesn't touch what's already stored.
The new check applies only to incoming announcements. Startup still reads existing gossip_store records, so a malicious record saved before the crash survives the upgrade, and every restart reloads the same trigger. Bansal said the operator must manually remove the offending record to restore the node.
Cleanup on its own doesn't close the hole either. According to the disclosure, an attacker can resend the same announcement to a vulnerable installation for as long as the attacker-controlled funding output stays unspent.
What's at stake for node operators
v26.04.1 was the first release to fix the defect. As of November 2, the project's latest release is v26.06.9, issued October 7, which maintainers strongly recommend installing.
The risk isn't only downtime. Bansal warned that an offline node can't watch the chain for a revoked channel state or a time-limited payment claim, and that missing those events could put funds at risk.
Frequently asked questions
Which Core Lightning versions are affected by the crash flaw?
Researcher Nishant Bansal's October 24 disclosure lists Core Lightning v25.02 through v26.04 as affected. v26.04.1, shipped April 25, was the first release to fix the defect. As of November 2, maintainers strongly recommend installing v26.06.9, issued October 7.
Why does a Core Lightning node keep crashing after the upgrade?
The patch only validates incoming announcements. Startup still reads records already saved in gossip_store, so a malicious announcement stored before the crash reloads the same trigger on every restart. Bansal said the operator must manually remove the offending record to restore the node.
How did the malicious announcement crash the node?
The announcement named the same previously unknown node as both endpoints. The routing graph tried to insert that node twice, a duplicate safeguard aborted gossipd, and Core Lightning treated the failure as fatal to the whole node. The fix requires the first node ID to be strictly less than the second.
