Core Lightning versions v25.02 through v26.04 can repeatedly crash after a malformed channel announcement is saved to disk. Researcher Nishant Bansal disclosed the flaw on October 24: upgrading prevents new malicious announcements from being stored, but does not remove a trigger already present in the node’s gossip_store.
Why it matters
The announcement lists the same previously unknown node as both endpoints. Vulnerable software accepts and stores it before the routing graph detects the duplicate. That causes gossipd, the component that handles announcements, to abort, and Core Lightning treats the failure as fatal to the node.
The fix checks that the first node ID is strictly less than the second, rejecting equal IDs. Core Lightning merged PR #9082 on April 24 and released the fix in v26.04.1 on April 25. But the validation applies to incoming announcements; startup still reads records saved before the upgrade. Bansal says operators must manually remove the offending record.
Market impact
The disclosure makes clear that installing the patch and cleaning up an affected node are separate steps. Cleanup alone also does not prevent another crash if the attacker-controlled funding output remains unspent and the announcement is sent again. Bitcoin Optech notes that releases before v25.02 could relay the announcement without crashing themselves, so an attacker did not need a direct connection to every vulnerable node.
The operational concern extends beyond downtime. An offline Lightning node cannot monitor the chain for a revoked channel state or act on a time-limited payment claim before it expires, potentially putting funds at risk. As of November 2, the latest release was v26.06.9, issued October 7, which maintainers strongly recommend installing.
Frequently asked questions
-
Which Core Lightning versions are affected by the disclosed flaw?
The disclosure identifies versions v25.02 through v26.04 as affected.
-
Why can a node keep crashing after its software is upgraded?
The upgrade blocks new malformed announcements but does not remove a trigger already saved in gossip_store. Startup reloads that record, causing the crash to recur.
-
What makes the malformed channel announcement crash Core Lightning?
It names the same previously unknown node as both endpoints. The routing graph detects the duplicate, causing gossipd to abort and the node to treat the failure as fatal.
-
What must an operator do beyond installing the fix?
The offending record must be manually removed from gossip_store. Cleanup alone may not prevent another crash if the attacker-controlled funding output remains unspent and the announcement is resent.
-
How can downtime put Lightning funds at risk?
An offline node cannot monitor the chain for a revoked channel state or act on a time-limited payment claim before it expires.
CryptoSlate