Bitcoin Core Lightning's v26.06.7 Docker images lied for days: check your digest now

Some Lightning node operators upgraded to v26.06.7 and got a binary that says one thing while doing another. That's not a riddle. It's a Docker packaging failure that left four image tags carrying unpatched software between Aug. 28 at 16:04 UTC and Sept. 1.

Core Lightning maintainers caught it, corrected it, and posted a notice telling anyone who pulled those images to verify them against a new digest. But the fix is manual, the window is narrowing, and the source embargo lifts on Sept. 11.

The five-day window nobody asked for

Here's how the timeline breaks down. On Aug. 28, Core Lightning released v26.06.7, a security patch bundled with a 14-day source embargo. The idea was to keep the fixes under wraps until operators had time to adopt them. That's a sensible lockdown: publish the binaries, hold the source, and let everyone patch before attackers can diff the code.

But the automated Docker build process had other plans. It published images from a placeholder tag. Four tags were affected:v26.06.7,latest,v26.06.7-vls, andlatest-vls. Anyone who pulled one of those between late August and Sept. 1 received a binary that reported itself as v26.06.7 at startup while lacking the release's actual fixes.

There's no precise end time in the maintainers' notice. That's part of what makes this dangerous. It's not like a binary that fails to start or crashes on launch. It starts fine. It runs fine. It just doesn't contain the patch.

So an operator who pulled the image on Aug. 30 could have spent a week believing they were protected.

The maintainers have since replaced the tags and removed every reference to the incorrect manifests. Good. But if you already pulled a faulty image, your local copy won't fix itself. You need to compare the image digest against the corrected values and re-pull if it doesn't match.

Trust the digest, not the banner

This is where I've to rant a little. The software's own version output was wrong. Not because of a malicious actor, but because the packaging pipeline didn't align the binary with the tag. And that reveals something uncomfortable about how many operators verify their infrastructure.

You can't trust what the software says about itself when what you're checking is whether the software is actually what it claims to be. It's circular. The version string comes from the same artifact you're trying to validate.

In commercial real estate, you don't close a deal because the sign on the building says the right name. You check the deed. You search the title registry. You verify the chain of ownership. You can tokenize the deed, but you can't tokenize the plumbing leak. And in this case, the plumbing is leaking.

The image digest is the title registry. The version banner is just curb appeal.

For standard images, the corrected digest forv26.06.7andlatestissha256:0421a5f0d1b2e1ad639edfa17d777816040e3850d91bae7f2d32186d9c1e6da4. The VLS tags,v26.06.7-vlsandlatest-vls, should matchsha256:6a5e05c13a65613f8c0fe3830c60248a6724e7206c1c23dd26ac2e98a3e72c1f.

You can inspect your local image with this command:

docker image inspect --format '{{index.RepoDigests 0}}' elementsproject/lightningd:v26.06.7

If the output doesn't match the corrected digest, pull the image again:

docker pull elementsproject/lightningd:v26.06.7

For thelatesttag, rundocker pull elementsproject/lightningd:latest. And VLS users have an extra step: theVLS_CLN_VERSIONsetting must also point tov26.06.7, orremote_hsmd_socketwon't start. The signer itself remains at VLS v0.14.0.

Then there's the second trap. If you tried to build v26.06.7 from GitHub's automatically attached source archive, stop. Those archives aren't the v26.06.7 source. Building them won't produce the patched binaries. Maintainers flagged this too. So the packaging error had a companion problem in the release process.

People pinned to v26.06.6 or earlier didn't run into the faulty Docker tags. But don't mistake that for safety. Those older versions are still missing whatever security fixes v26.06.7 was meant to deliver. You're not protected by default. You're just outside this specific failure mode.

The Sept. 11 clock is ticking

Now the real deadline. The source for v26.06.7 is scheduled to be published on Sept. 11, which is 14 days after the Aug. 28 release. As of Sept. 8, the notice still lists that disclosure as upcoming. Once those diffs go public, anyone with the skills can reverse-engineer the fixes and start probing for unpatched nodes.

That means the window between now and Sept. 11 is the only cushion you've. Every node still running a faulty image after that day is effectively running a known-vulnerable binary with the patch details printed in the public record.

How many operators will actually check their digest before then? The honest answer is probably not enough. Docker's tag model has always been loose. Tags move. They get overwritten. A version number isn't a commitment to a specific artifact. Reproducible builds and signed digests address that, but they're not universal yet in Bitcoin infrastructure.

The compliance layer is where most of these platforms will live or die. And that applies to node operations too, not just securities tokenization platforms. If you aren't treating image verification as a requirement, you're running on faith. Faith doesn't patch vulnerabilities.

It's worth asking yourself one question. If a startup banner can't be trusted to reflect the actual state of the code, what else in your deployment pipeline is quietly lying to you?

The Lightning network handles real value, even if it's not the kind of fractional real estate I usually cover. It's channel liquidity, routing fees, and Bitcoin itself. A node operator can shrug off a bad Docker image if the node is a hobby. But for routing nodes with significant channel balances, an unpatched binary after Sept. 11 is an open invitation.

So do the check. If the digest comes back clean, you're done. If it doesn't, re-pull and restart. Then move on to the next thing. The fix here's simple, manual, and undramatic. That doesn't make it optional.

The real estate industry moves in decades. Blockchain wants to move in blocks. But this week, blocks won't save you. Only a digest comparison will.