Bitcoin Core Lightning Docker bug leaves node operators exposed despite showing updated version
Heads up, Lightning node operators: a packaging goof meant some Docker images claimed to be the patched v26.06.7 but actually contained older, unpatched binaries. Your container might say it’s upgraded, but the internals could be lying.
What happened
Between Aug. 28 (around 16:04 UTC) and Sept. 1, four Docker tags for the Lightning implementation were published with incorrect image contents. The tags affected are v26.06.7, latest, v26.06.7-vls and latest-vls. An automated build process accidentally pushed images from a placeholder tag, so those images reported the startup version v26.06.7 while not including the release’s security fixes.
The maintainers have since replaced the bad images and removed references to the wrong manifests, but if you pulled one of the faulty images during that window and still have it locally, the version string shown at container startup is not a reliable indicator that the fixes are actually present.
How to check and fix it
Don’t trust the printed version — check the image digest (the image’s fingerprint/hash) for your pulled image and compare it to the corrected values published by the maintainers. If the digest doesn’t match, re-download the corrected image with the proper tag.
If you use the VLS builds, pay attention to the separate VLS digest and also ensure your VLS_CLN_VERSION is set to v26.06.7; otherwise remote_hsmd_socket may refuse to start even after you swap images. Note that the VLS signer itself remains at v0.14.0.
Operators staying on v26.06.6 or earlier were unaffected by this packaging error — the bug was in the image publishing, not in those older releases. Still, the security fixes are part of v26.06.7, so anyone who intended to upgrade will want to confirm they actually received the patched image.
One more trap: during the release embargo, automatically attached source archives on code hosting platforms might not be the real v26.06.7 source. Building from those auto-packaged archives may not yield the patched binaries, so don’t assume a freshly built binary from an attached archive is safe until the maintainers publish the verified source.
Short version: if you pulled one of the four tags during the affected window, check the digest and re-pull if it’s different. Treat the container’s printed version string like an overconfident parrot — it might be repeating what it heard, not what’s actually inside.
