Core Lightning 26.06.7: Check the Artifact Before Restart

Core Lightning 26.06.7 belongs in your next controlled upgrade window, but confirming the artifact matters more than confirming the version string. The security release contains fixes for undisclosed vulnerabilities reported during August, requires a lightningd restart and performs any necessary database changes automatically at startup. The immediate trade-off is unusual: operators must trust signed binaries before they can inspect the source, which is scheduled for publication on September 11.

Why must Docker operators verify the 26.06.7 image?

Docker operators must verify the image because some containers labeled 26.06.7 did not contain the security fixes. From August 28 at 16:04 UTC until September 1, automated publishing built the v26.06.7 and latest tags from a placeholder tag. Those images announced the expected version during startup, so checking lightning-cli getinfo or a startup log could produce a false assurance.

The execution path is the operational failure here: CI selected a placeholder tag, the registry attached mutable release labels, the operator pulled one of those labels, and the process reported the intended version. Trusting metadata gave the publishing system permission to define what “26.06.7” meant. The corrected standard image has manifest digest sha256:0421a5f0d1b2e1ad639edfa17d777816040e3850d91bae7f2d32186d9c1e6da4. Images pinned to 26.06.6 or earlier were not part of this packaging incident, though they still lack the new security fixes.

• Inspect the local image digest rather than relying on its tag or reported version.
• Re-pull 26.06.7 if the digest differs from the published value.
• Verify downloaded tarball checksums and maintainer signatures before installation.
• For VLS, change VLS_CLN_VERSION to v26.06.7 before restarting.

Should operators wait for the Core Lightning source code?

Operators should install a verified binary now rather than remain exposed while waiting for the source. The project’s 14-day embargo denies attackers an immediate patch diff while giving nodes time to update. That reduces disclosure risk, but it temporarily replaces the normal inspect-build-deploy procedure with trust in maintainer signatures and signed checksum manifests.

A signed manifest already commits to the withheld source archive’s checksum, so the source published after the embargo can be checked against that prior commitment. It does not yet let an operator audit the vulnerable execution path or reproduce the installed binary. The release also used non-default optimization settings; exact reproduction instructions are promised with the source. I would accept that temporary verification gap because the alternative is knowingly running a superseded security build.

What should the Core Lightning upgrade runbook change?

The runbook should promote artifact identity, signer verification and post-restart health checks to release gates. Schedule a brief payment and routing interruption, record the current database backup and image digest, install the signed artifact, then restart and confirm peer reconnection, block synchronization, channel states and plugin availability. Alert when a running container’s digest differs from the approved manifest—not merely when its version is old.

Keep the previous binary or container reference and the pre-upgrade database backup as separate recovery assets. The documentation says no manual database migration is required beyond automatic startup work, but it does not establish that downgrading those updated files is safe. Until that rollback path is tested, recovery should mean restoring the matching backup with the previous build, not starting an older binary against the post-upgrade database.