Core Lightning patches flaw that could let peers broadcast revoked channel states

Core Lightning, one of the most widely deployed Lightning Network node implementations, has patched a flaw that could have let a peer broadcast an outdated, revoked channel state without triggering the penalty meant to punish cheating. The fix shipped quietly in late August but was only explained publicly by Bitcoin Optech’s newsletter on Friday, September 25, 2025, giving operators still running older builds a clear picture of what they were exposed to.

• Core Lightning shipped the fix in v26.06.7 on Aug. 28, with source code released after an embargo on Sept. 11.
• The flaw only applied when a peer skipped naming an upfront shutdown script at channel open, then matched outputs later.
• Docker images tagged v26.06.7 between Aug. 28 and Sept. 1 reported the new version number but shipped without the actual fixes.

• Aug. 28 date Core Lightning shipped the embargoed v26.06.7 fix
• Sept. 22 date v26.06.8 landed with further security fixes
• Sept. 25 date Bitcoin Optech publicly detailed the already-shipped patch
• 5 days window, Aug. 28 to Sept. 1, images ran without the fix

According to reporting by CryptoSlate, the bug sat in how Core Lightning distinguished a legitimate cooperative channel close from a broadcast of an old, already-revoked commitment. In Lightning, peers continually replace earlier commitments as channel balances shift, and the protocol’s penalty mechanism exists specifically to let an honest party seize funds if a counterparty ever tries to cheat by publishing a stale state.

Revoked commitment could pass as a legitimate close

Before the fix, Core Lightning could mistake a revoked commitment broadcast for a cooperative close whenever its outputs happened to match shutdown scripts already on file. That mistake depended on one specific setup: a peer that had not specified an upfront shutdown script when the channel opened could later name the output script of its own revoked commitment inside a shutdown message.

It could then abandon the cooperative close and broadcast the old commitment instead. Matching outputs alone made the transaction look legitimate, bypassing the penalty path, according to the maintainers’ patch notes and regression test.

The repair, carried into the main branch through pull request 9509 merged on Sept. 15, checks a transaction’s locktime and sequence encoding to identify a commitment before ever treating its outputs as a possible mutual close. The maintainers describe this as a potential way to evade the penalty rather than a confirmed instance of theft, and stress it is a channel-handling issue specific to Core Lightning, not a change to Bitcoin’s base-chain rules.

Docker images misreported their own version for five days

A separate problem complicated the rollout for operators who run Core Lightning through Docker. The project’s v26.06.7 release notes disclose that images served under that tag and related tags between Aug. 28 and Sept. 1 reported the new version number on startup while still lacking its fixes.

That five-day mismatch meant an operator could believe they had already patched when they had not. The project has published the corrected image digests and instructs anyone with a mismatched digest to re-pull the image.

V26.06.8 is the version the project now recommends

The version history splits into two distinct patches. Core Lightning shipped v26.06.7 on Aug. 28, then published its initially embargoed release source on Sept. 11, before the PR carrying those changes merged on Sept. 15.

V26.06.8 followed on Tuesday, Sept. 22, 2025, bundling additional security fixes with immediately available source, though the project notes a few tests remained withheld. Optech’s Sept. 25 write-up explained the revoked-close repair after the fix had become available in v26.06.8.

Any Core Lightning build older than the fixed v26.06.7 release needs updating, and the project strongly recommends jumping straight to v26.06.8 rather than stopping at the earlier patch. Because the revoked-close path requires the specific shutdown-script condition described above, running a vulnerable version does not mean every open channel was exposed to it.

The BlockWest read. The bigger exposure here sits with custodians and exchanges running Lightning liquidity at scale, not solo node operators who read release notes closely. A five-day window where Docker images silently misreported their own patch status is the kind of gap that automated fleets, not individual hobbyists, are built to miss. Any institution routing customer funds through Core Lightning should treat digest verification as a standing operational control, not a one-time checklist item.

The Core Lightning project has not stated that any funds were actually lost to this path, only that the mechanism existed and has since been closed. Operators still running builds older than v26.06.7, or Docker images pulled during the Aug. 28 to Sept. 1 window, are being told to verify their image digest against the corrected list and upgrade to v26.06.8 without waiting for further confirmation of real-world exploitation.

BlockWest is a news publication. Nothing here is investment advice. Read our disclaimer and editorial policy.