Core Lightning Nodes Keep Crashing After an Upgrade Because the Trigger Stays on Disk

Bitcoin’s Lightning Network has a peculiar new headache: some Core Lightning nodes that were attacked keep crashing even after their operators upgrade to the patched software. The reason, as researcher Nishant Bansal’s Oct. 24 disclosure explains, is that the malicious trigger was already saved to disk — and upgrading does not delete it.

The flaw affects Core Lightning versions v25.02 through v26.04. Once a malicious channel announcement is stored, every restart reloads the same trigger, and the operator must manually remove the offending record to restore the node.

How a routing announcement became a kill switch

Channel announcements are how Lightning nodes learn about connections in the network’s routing graph — the map that makes payments possible. The attack exploits a simple logical flaw: Bansal’s crafted announcement named the same previously unknown node as both endpoints of a channel, effectively telling the network that a node was connected to itself.

Vulnerable software accepted the announcement and wrote it to the node’s on-disk gossip_store before loading it into the routing graph. The graph then tried 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.

In other words, a single malformed message could take a node offline and keep it offline, because the poison was persisted before the crash.

Patched in April, disclosed in October

Here is where the timeline gets interesting. Bitcoin Optech highlighted the issue on Oct. 30, but the preventive patch is months old. Core Lightning merged the fix — PR #9082, which validates endpoint ordering before accepting an announcement — on April 24 and shipped it in v26.04.1 on April 25. Requiring the first node ID to be strictly less than the second also rejects equal IDs, stopping the malformed input from ever being accepted or stored.

The October disclosure explains the residual problem: the validation check applies to incoming announcements, but startup still reads whatever records are already in gossip_store. An upgrade does not remove a malicious record saved before the crash.

Cleanup alone is not enough

Bansal’s recovery guidance requires manually removing the malicious record from gossip_store. But that is only half the fix. The disclosure warns that an attacker can simply resend the same announcement while the attacker-controlled funding output remains unspent, re-crashing a still-vulnerable installation.

There is also a relay risk: Bitcoin Optech notes that Core Lightning releases before v25.02 could accept and propagate such announcements without crashing themselves. An attacker never needed a direct connection to every vulnerable node — older, oblivious nodes could do the delivery work.

For operators choosing an upgrade now, v26.04.1 marks the first fix for this defect. As of Nov. 2, the project’s latest release is v26.06.9, issued Oct. 7, which maintainers strongly recommend installing.

Why downtime is about more than downtime

The most underappreciated part of the disclosure is what an offline node cannot do. Bansal warns that a downed node cannot watch the chain for a revoked channel state — the mechanism that punishes a cheating counterparty — or for a time-limited payment claim that must be made before expiry. Missing either event can put funds directly at risk.

That elevates this from an availability nuisance to a potential security issue. A node stuck in a crash loop is not just failing to route payments; it is failing to defend the funds it is custodied to protect. For merchants and routing operators running Core Lightning, that reframing matters.

Lessons for the wider ecosystem

For everyday crypto users, the story is mostly reassurance: the Lightning Network’s design confines this flaw to Core Lightning nodes, funds in properly watched channels remain protected by the network’s built-in incentive structure, and a fix has existed since April. If you run a Lightning node on Core Lightning and have not upgraded past v26.04.1, this is the moment — and if you suspect you were hit, check your gossip_store before assuming the upgrade alone will save you.

For developers, the deeper lesson is about persistence. Validation that only guards the front door is not enough when the attacker’s payload has already moved in. Any system that writes untrusted input to disk and reloads it at startup inherits this class of bug, and the gap between a preventive patch (April) and a full understanding of the recovery path (October) shows how long residual risks can hide behind a “fixed” label.

Bitcoin’s security culture runs on exactly this kind of slow, public forensics — unglamorous, months after the fact, and quietly essential to keeping the network’s plumbing trustworthy.