Repeated Crashes of Core Lightning Nodes Linked to Undeleted Malicious Triggers After Upgrade

Core Lightning Vulnerability Identified

A vulnerability in Core Lightning, the software that facilitates Bitcoin’s Lightning payment network, has been identified, posing a risk of repeated node failures upon reboot, even following updates. This issue was brought to light by researcher Nishant Bansal on October 24, who specifically noted that versions v25.02 to v26.04 are susceptible to the flaw. The glitch is linked to certain malicious announcements that, once saved, initiate the same crash upon restarting the node, necessitating manual deletion of the offending data to restore normal function.

Previous Solutions and Current Recommendations

On October 30, Bitcoin Optech drew attention to the reported problem, although the solution has been in place for several months. A corrective measure had been integrated into Core Lightning on April 24 as part of pull request #9082, with the patched version v26.04.1 being released on April 25. Bansal’s recent findings underscore that the flaw's preventive fix has existed since then.

Understanding the Vulnerability

In the Lightning network, channel announcements convey information about node connections within the routing framework. The vulnerability arose when a channel announcement incorrectly identified the same unknown node as both ends of a connection. The flawed version of Core Lightning accepted this announcement and stored it in the gossip_store. Upon loading this corrupted data into the routing graph, the system encountered duplicate node entries. A safety mechanism designed to handle such duplicates aborted the processing component, called gossipd, leading Core Lightning to classify this mishap as a critical failure, effectively crashing the entire node.

Patch Implementation and Ongoing Risks

The implemented patch ensures that the order of node IDs is validated before an announcement is accepted, disallowing instances where both IDs are identical. This measure effectively blocks malformed announcements from being stored. However, it is important to note that even after the update, the existing records in gossip_store will still be accessed during startup, meaning that operators must manually eliminate any harmful stored records to prevent crashes after upgrades.

Furthermore, even if prompt action is taken to remove those records, nodes remain vulnerable to new attacks. The disclosure points out that an assailant could resend the same malicious announcement while linked to an unspent funding output, leading to further complications. Bitcoin Optech highlights that versions prior to v25.02 had the ability to accept and relay such announcements without crashing, indicating that attackers didn’t need to connect directly to compromised nodes.

Recommendations for Operators

For operators considering updates, v26.04.1 represents the first rectification of this critical defect. As of November 2, the latest available release is v26.06.9, which debuted on October 7, and project maintainers highly recommend its installation. Downtime due to the vulnerability poses additional risks related to payment monitoring. Bansal cautions that an offline node cannot monitor the blockchain for vital events, such as a revoked channel state or a time-sensitive payment claim, missing which could jeopardize funds.