Channel Management

Core Lightning, a Lightning Network node implementation, has patched a channel-closing flaw that let a peer broadcast an old, revoked commitment without triggering the penalty meant to punish cheating. The fix, folded into release v26.06.7 and forward-ported to the main codebase on Monday (Sept. 15), matters because it touches the core economic guarantee that makes Lightning channels safe to leave unmonitored.

• Core Lightning shipped the fix in v26.06.7 on Aug. 28, then published the source publicly on Sept. 11.
• Pull request 9509, merged into the master branch on Sept. 15, carried the shutdown-script fix forward for future releases.
• Docker images tagged v26.06.7 between Aug. 28 and Sept. 1 reported the new version number but lacked the actual fixes.

• v26.06.7 release that patched the revoked-close penalty bypass
• Sept.15 date the fix was forward-ported into Core Lightning’s master branch
• Aug28-Sept1 window when Docker images misreported an unpatched build as fixed

Lightning channels work because each side can punish the other for broadcasting an outdated, revoked balance. Before the fix, Core Lightning could instead mistake that cheat for a routine cooperative close, letting the penalty path go unused. Bitcoin Optech’s Sept. 25 explanation made the already-shipped patch legible to operators.

PR 9509 Closes the Shutdown-Script Loophole in Revoked Commitments

The bug required a specific setup. A peer that had not specified an upfront shutdown script when opening a channel could later name the output script of its own revoked commitment inside a shutdown message.

It could then abandon the cooperative close and broadcast that old commitment instead. Because every output matched a shutdown script already on record, Core Lightning read the funding spend as legitimate and skipped the penalty check.

The patch adds a regression test confirming the fix. The fix now checks a transaction’s locktime and sequence encoding to recognize a commitment before it ever considers the outputs as a possible mutual close.

Docker Images Misreported the Fix for Four Days

Operators who pulled Core Lightning through Docker during the initial rollout face a separate risk. The project’s release notes say images served under the v26.06.7 tag between Aug. 28 and Sept. 1 reported the corrected version number on startup while still running the vulnerable code underneath.

The project has since published corrected image digests and told users with a mismatch to re-pull the image. Anyone running a build older than v26.06.7, or a Docker image from that four-day window, should treat the update as unfinished.

Core Lightning now strongly recommends v26.06.8, released Sept. 22 with additional security fixes and immediately available source, though maintainers note a few tests remain withheld. That sequencing matters: an operator who updated on Aug. 28 assuming they were safe may not have been, depending on which artifact they pulled and from where.

What Changes in Practice, and What the Patch Notes Do Not Say

For channel operators, the practical shift is narrow but consequential. Previously, a counterparty exploiting the shutdown-script gap could walk away from a stale channel state without forfeiting funds to the penalty transaction that is supposed to deter exactly that behavior.

After the fix, Core Lightning checks transaction shape before it checks outputs, closing that path regardless of whether a peer specified an upfront shutdown script at open time.

The pull request’s own maintainers are careful to frame this as a narrowed capability rather than a confirmed loss: it documents “a potential way to evade the penalty,” not a recorded theft. What the materials do not establish is how many live channels ran the vulnerable configuration, or whether any counterparty attempted the exploit before Optech’s disclosure made it public.

The developers also note this is a Core Lightning implementation issue, not a change to Bitcoin’s base-chain consensus rules, so other Lightning node software is unaffected by this specific defect.

The CCS read. This is a routine implementation bug, not a protocol failure, but it is the kind institutional custodians running Lightning infrastructure need surfaced fast. The real exposure sits with operators who trusted a version string rather than a digest during the Aug. 28 to Sept. 1 window, a gap that ordinary node monitoring would not have caught without Optech’s writeup.

Core Lightning maintainers have not disclosed whether any node operator’s channel was actually exploited under the pre-patch behavior, and the project has not said how many Docker deployments still carry the mismatched Aug. 28 to Sept. 1 digest. Operators on builds older than v26.06.8 are the open question until they confirm and re-pull.