Core Lightning flaw can keep nodes crashing after an upgrade until a stored trigger is removed

A disclosed flaw in Core Lightning, software for Bitcoin's Lightning payment network, can leave a node crashing on every restart even after an upgrade, because the malicious announcement that triggered the crash remains stored on disk.

Researcher Nishant Bansal disclosed the issue on October 24, identifying versions v25.02 through v26.04 as affected. Once the announcement has been saved, each restart reloads the same trigger, and Bansal says the operator must manually remove the offending record to restore the node.

Bitcoin Optech, a technical newsletter that tracks Bitcoin engineering developments, highlighted the issue on October 30, but the preventive patch is months old. Core Lightning merged pull request #9082 on April 24 and shipped the fix in release v26.04.1 on April 25. The October disclosure therefore explains a flaw whose preventive fix had been available since April.

Why the patch does not clear a stored trigger

Channel announcements tell nodes about connections in the Lightning routing graph. Payments hop across these recorded connections, so every routing node depends on an accurate copy of the graph to move funds. In this case, a crafted announcement named the same previously unknown node as both endpoints. Vulnerable software accepted it, wrote it to the on-disk gossip_store, and then loaded it into the routing graph.

The graph then attempted to insert that node twice. A safeguard against duplicates aborted gossipd, the component that handles these announcements, and Core Lightning treated that failure as fatal to the entire node.

The patch checks endpoint ordering before accepting an announcement. Requiring the first node ID to be strictly less than the second also rejects equal IDs, preventing the malformed input from being accepted and stored in the first place.

The validation applies, however, only to incoming announcements. Startup still reads records already present in gossip_store, and upgrading does not remove a malicious record saved before the crash. That is why Bansal's recovery requirement is manual removal of the malicious record from gossip_store.

Cleanup alone also leaves a vulnerable installation open to another crash: according to the disclosure, an attacker can resend the same announcement while the attacker-controlled funding output—the on-chain output that opened the channel—remains unspent.

Relay exposure, upgrade guidance, and downtime risk

Bitcoin Optech notes that Core Lightning releases before v25.02 could accept and relay such announcements without crashing themselves. An attacker therefore did not need a direct connection to every vulnerable node, since a relayed announcement is forwarded onward to each node's peers and can carry the malformed record deeper into the network.

For operators choosing to upgrade now, v26.04.1 marks the first release containing the fix for this defect. As of November 2, the project's latest release is v26.06.9, issued October 7, which maintainers strongly recommend installing.

Downtime carries a payment-monitoring risk beyond unavailable service. In Lightning, enforcing channel rules falls on the node operator. Bansal warns that an offline node cannot watch the chain for a revoked channel state or a time-limited payment claim that must be made before expiry. Missing those events can put funds at risk.

Original reporting: CryptoSlate