An automated build process published the images from a placeholder tag. Maintainers say they have replaced them and removed every tag’s reference to the incorrect manifests. But an operator who retained a faulty image cannot rely on its startup version to confirm the patch arrived.
The Aug. 28 release set a 14-day embargo on publishing its source, pointing to a planned Sept. 11 disclosure. As of Sept. 8, the notice still describes that publication as upcoming. Maintainers say the delay gives operators time to upgrade before prospective attackers can reverse-engineer the fixes.
How to check the Docker image to fix the Lightning bug
Maintainers ask anyone who previously pulled one of the four tags to compare its digest, the image’s identifying hash, against the corrected values:
For the standard versioned image, the notice supplies this command to inspect the local image. Its output alone does not establish which image an existing container is running:
docker image inspect --format '{{index .RepoDigests 0}}' elementsproject/lightningd:v26.06.7
If the digest differs, its corresponding download command is:
docker pull elementsproject/lightningd:v26.06.7
The notice also supplies docker pull elementsproject/lightningd:latest for that tag. VLS users need the separate VLS digest in the table. Their VLS_CLN_VERSION setting must also match v26.06.7, or remote_hsmd_socket will refuse to start; the signer itself remains VLS v0.14.0.
Users pinned to v26.06.6 or earlier escaped this packaging mistake. The exemption concerns the faulty packaging; the new security fixes belong to v26.06.7.
The packaging correction changes the operator’s immediate problem of an attempted upgrade may need to be checked again while that window remains open.
Another download trap exists during the embargo. GitHub’s automatically attached source-code archives are not the v26.06.7 source, maintainers warn, so building those archives will not produce the advertised patched binaries.
