Bitcoin Core Lightning Docker bug exposes node operators despite version label
In brief
- Four Docker tags delivered unpatched binaries reporting v26.06.7 between Aug. 28–Sept. 1
- Automated build process published images from placeholder tag, masking packaging error
- Node operators must verify patches via Docker image digest, not startup version strings
The Packaging Mistake
The affected Docker tags were v26.06.7, latest, v26.06.7-vls, and latest-vls. An automated build process published the unpatched images from a placeholder tag, allowing faulty binaries to reach operators who pulled those tags expecting patched code. The images circulated between August 28 at 16:04 UTC and September 1.
This creates a window where node operators may have pulled what appeared to be the latest release without receiving the security fixes it advertised. Version strings alone became unreliable.
Verification and Remediation
Maintainers replaced the faulty images and removed every tag's reference to the incorrect manifests. But the fix came with a caveat: an operator who retained a faulty image cannot rely on its startup version to confirm the patch arrived. Instead, affected operators must compare their Docker image digest against corrected values to verify they have the patched version.
The digest—a cryptographic hash unique to each image—is the only reliable proof. Version numbers, in this case, lied.
The Embargo and Source Code Risk
The v26.06.7 release imposed a 14-day embargo on publishing its source code, with disclosure planned for September 11. This delay was meant to give operators time to patch before attackers could reverse-engineer the fixes from public code. The Docker bug compressed that window for anyone who pulled the faulty images.
There's another layer: GitHub's automatically attached source-code archives for v26.06.7 are not the actual v26.06.7 source, and building them will not produce the advertised patched binaries. Operators who tried to build from GitHub's archives would end up with unpatched code anyway.
Users pinned to v26.06.6 or earlier were not affected by the packaging mistake, meaning the exposure was isolated to those who upgraded specifically to v26.06.7 during the affected window.
