Is Your Docker Update Verified?

When your Core Lightning node prints v26.06.7 at startup, that is no proof that the security fixes in this version are actually running. Anyone who pulled their updateay be running an image that reports itself correctly and still does not contain the fixes. The reliable evidence is the image digest, not the version output. This piece walks you through the check that requires, and through what to do afterwards

The situation has changed in two places since our article of August 30: the faulty Docker window is now documented in the release note, and the embargo on therator need to do

What Core Lightning is and why this update concerns you

Core Lightning (formerly c-lightning) is one of three widely used implementations of the Lightning protocol, written in C and maintained in the ElementsProject/lightning repository. An implementation here is simply a standalone program that applies the same network rules as the competing programs but has its own code and therefore its own bugs.

The Lightning network itself is a second layer on top of the <a href="https://xpertsstudio.com/crypto-treasury-firms-stack-bitcoin-ethereum-and-solana/” title=”Crypto Treasury Firms Stack Bitcoin, Ethereum and Solana”>Bitcoin blockchain: two parties jointly lock funds in a payment channel and then settle any number of payments between them without writing every single one to the chain. Whoever runs such a node holds the keys to those locked funds themselves. That is what makes this serious: a bug in the node software directly affects Bitcoin that belongs to you and that nobody else is watching over.

Self-custody means taking responsibility, and that does not end with storing the key. It also covers the question of whether the software using that key matches the state you believe you have installed. If you would rather hold your assets without running a server service, you will find the devices for that in our hardware wallet comparison. For a Lightning node, though, there is no way around keeping running software current.

What went wrong with the Docker image of version 26.06.7

Version 26.06.7 was released on August 28, 2026 as a maintenance release. The project’s announcement is terse: it is a point release fixing confirmed vulnerabilities that had been reported to the team over the preceding three weeks. A point release is an interim version containing fixes only and no new features.

For Docker users, something went wrong in the process. The release note was subsequently extended with a section that names the error outright: between August 28 at 16:04 UTC and September 1, four tags served images that reported v26.06.7 at startup but did not contain that version’s fixes. The affected tags were v26.06.7, latest, v26.06.7-vls and latest-vls.

The project names the cause itself: an automated build process had published the images from a placeholder tag. They have since been replaced, and the wrong manifests are no longer referenced by any tag. A manifest is the descriptor file that defines which individual parts make up a container image. Anyone still holding the wrong version locally will notice nothing of this correction, however: what you downloaded back then stays on your machine.

One point clears a group of operators entirely. Anyone pinned to v26.06.6 or older was never affected at any point, according to the project. The problem only hits those who pulled 26.06.7 or latest during the window described.

Why the version number at startup is no proof of the patch level

The obvious check is also the useless one. A call that prints the running version merely reads out a string written into the program at build time. If that string comes from a placeholder tag, then an unpatched program truthfully reports the number it was handed and tells you nothing about the actual code.

That is the awkward part of our own article of August 30: there we had you check the version. For Docker operators inside the affected window, that check was worthless, without any way of telling at the time. Hence this follow-up, and hence a different check from here on.

The digest is the check value that uniquely identifies a container image. It is a cryptographic hash over the manifest, and therefore over the actual content of the image. A tag such as latest is a moving pointer that can point at one image today and another tomorrow. The digest cannot do that: change a single byte of the content and the value changes. It is therefore the only piece of information that tells you what you are really running.

Are you affected? The window, the tags and the three platforms

Three questions settle the case. First: did you obtain the software as a container at all? Anyone who installed the tarballs from the release page was never affected, because those archives were the right ones from the start. Second: did your download fall inside the window between August 28 at 16:04 UTC and September 1? The release note gives no exact time for the end of that window, so a degree of fuzziness remains, and in case of doubt it is better to check once too often. Third: did you use one of the four tags named?

Anyone unsure about all three questions is always right to run the digest check. That check costs you a single command and answers the question conclusively, no matter when and how you obtained the image.

There are three platforms for this version’s images: linux/amd64, linux/arm64 and linux/arm/v7. The third has a peculiarity that concerns operators of small single-board computers: there is no release tarball for linux/arm/v7. The binaries for that platform are compiled separately and are covered by no signed manifest. Anyone working on that architecture therefore starts out with a weaker chain of evidence than on the other two. On top of that, according to the project the images carry neither provenance nor SBOM attestations, meaning no machine-readable proof of origin.

Keep your keys offline: hardware wallets compared

How to check the image digest of your Lightning node

The command named in the release note reads out the digest of the image held locally. It looks like this:

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

The output is the value you have to compare. The project names two target values for the corrected images. For the tags v26.06.7 and latest it reads sha256:0421a5f0d1b2e1ad639edfa17d777816040e3850d91bae7f2d32186d9c1e6da4. For the signer variant under v26.06.7-vls and latest-vls it reads sha256:6a5e05c13a65613f8c0fe3830c60248a6724e7206c1c23dd26ac2e98a3e72c1f.

Two notes on running it. The command queries your local store only, downloads nothing and changes nothing. And it refers to the tag you give it: if you work with latest, use latest; if you run the signer variant, use the respective -vls tag. If the value printed matches the target value character for character, you are done and running the corrected build.

What matters is comparing the full length. A quick glance at the first and last four characters is not enough, because that is precisely the part a human waves through as “close enough” when in doubt. Copy both values next to one another and compare them mechanically, for instance by writing the target value into a file and checking the output against it.

Digest does not match: how to pull the corrected image

If the value differs, the remedy is unspectacular. You pull the image again, for every tag you actually use:

docker pull elementsproject/lightningd:v26.06.7
docker pull elementsproject/lightningd:latest

Then check the digest again with the same command as above. Only once the new value matches the target value do you restart the container, so that the running process actually uses the fresh image. A pull on its own does not replace a running container; your node keeps running on the old state until it restarts.

Anyone running containers through a Compose file or an orchestrator should make sure the configuration does not fall back on a cached local state. The cleanest approach is to pin the verified digest itself afterwards instead of the moving tag. The same mix-up then cannot happen to you a second time, because the reference is bound to the content rather than to a name.

One change at the margin may show up on restart: in the current images, Core Lightning is installed to /usr/bin and /usr/libexec/c-lightning, whereas earlier images used /usr/local. Symlinks from the old locations are included, so hard-wired paths continue to work. Anyone running their own scripts with absolute paths should still give them a once-over.

VLS operators: why the signer has to match the node version

VLS stands for Validating Lightning Signer and denotes a separated signing service that holds the node’s keys and checks every signature against its own rules before issuing it. The point of it: even if the node is compromised, an attacker cannot talk the signer into arbitrary payouts.

For these operators there is a hard edge when moving to 26.06.7. According to the project, the v26.06.7-vls variant contains the same signer as v26.06.6-vls, namely VLS v0.14.0, which this release leaves untouched. The signer does, however, require the VLS_CLN_VERSION variable to match the node it talks to. If it still reads v26.06.6 while the node runs v26.06.7, remote_hsmd_socket refuses to start.

That is inconvenient but benign in effect: the service does not start at all rather than carrying on in a half-matching state. Set the variable during the upgrade and the signer stays reachable. Anyone who misreads the message and rolls the node back to the old version to get the signer running undoes precisely the fix this is all about.

The embargo has ended: what that means for unpatched nodes

The project had deliberately withheld the a patch shows which code it changes, and the delay was meant to lower the likelihood of attackers reverse-engineering the fixes and exploiting them before the network had updated

That period is over. The release note now says so in as many words: “The embargo has ended. The6.06.7 tag has since pointed at the commit the binaries were built from, and the

For you as an operator, that reverses the risk picture. Until September 11, an unpatched node was also protected by the fact that attackers did not know the details. That protection has fallen away with nothing to replace it, because the changes have been publicly readable ever since. Anyone who has not caught up by today is running software whose vulnerabilities are documented and open to inspection by anyone. The project also states that versions before 26.06.7 are no longer supported.

Notable on the side, and readable from the release metadata itself: the signature file for the amd64 checksums was not uploaded until September 12, 2026 at 06:02 UTC. Anyone wanting to verify the signature before that found none for this architecture. The checksum file itself, by contrast, had been available since August 28.

AdvertisementSoftware wallets compared: update routes and proof of origin

Why the –offline stopgap is no substitute for the update

The project announcement of August 28 included an interim step for everyone unable to update straight away. A restart with the --offline flag cuts the node off from incoming messages and thereby denies attackers any way of addressing it at all. The service keeps running and processes the blockchain, so it can still detect a cheating attempt by the channel partner. The project writes that the flag should be removed again after the upgrade and the node restarted.

This stopgap was intended for the period without public details. Since September 11 it is no longer a substitute for the update, only a bridge covering the hours you need to catch up. A sealed-off node forwards no payments, earns no fees and is unreachable for counterparties. As a permanent state, that is expensive downtime.

The same check routine is worth applying to other building blocks in your own setup. If you put a management interface in front of the node, you should know how reachable it is from the network as well; we described that route for Alby Hub on September 11. The starting point for this series of vulnerabilities is in our article of August 30, Core Lightning: what node operators have to do now.

Installed without Docker? How to verify checksums and signatures

Anyone obtaining the tarballs from the release page has the better chain of evidence but also has to walk it. Every binary is covered by a signed manifest. First you check the checksums:

sha256sum -c SHA256SUMS-v26.06.7 --ignore-missing

Then the signature over that checksum file:

gpg --verify SHA256SUMS-v26.06.7.asc SHA256SUMS-v26.06.7

The file SHA256SUMS-v26.06.7 covers the amd64 archives; for arm64 there is a separate file with its own signature. Four maintainers of the project signed, and the release note lists their fingerprints individually. One detail spares you a false alarm: a signature can report a fingerprint that differs from the one listed, because the signers use subkeys. Once the primary key is imported, gpg --verify resolves this itself, and the discrepancy is not a failed check.

There is a second, faster piece of evidence, and it is the genuinely elegant part of this release. The checksum file contained a line for the source archive clightning-v26.06.7.zip from the start, even though that archive was not yet public on August 28. Because the file was signed back then, it amounts to a commitment made in advance to exactly the bytes that are published now. That makes it possible to show in minutes and without a compiler that the source code visible today is the same one signed in August, and that nothing was altered during the embargo.

Reproducible builds: where the chain of evidence for this version ends

A reproducible build is a build process that produces the same binary byte for byte from the samehat a published file really does come from the publishednames the limitations itself

First, the archives were not built at the default optimisation level. The configuration uses -Og by default, while the published binaries were produced with -O3. Anyone checking out the tag and building normally gets files that do not match the checksums; COPTFLAGS=-O3 has to be passed explicitly. Second, the arm64 archives cannot be rebuilt from this state, because the tooling required for it is not in this version’s source tree. Those files remain verifiable through the signature but not independently reproducible. Third, the project points out that the Fedora rebuild may differ, because the build image there is freshly updated on every run and two people on different days can end up with different tool versions.

This reads as an honest description of a chain of evidence with gaps, not as criticism of the people involved. For you as an operator it means, in practice: rely on the signature and the checksum, and treat a full rebuild as a job for specialists rather than a step in your maintenance routine.

What this incident shows about supply chains in crypto software

The real lesson lies in the delivery and not in the vulnerability itself. The error arose in an automated build process that published an image from a placeholder. Nobody had to be attacked for it, and yet a file that did the wrong thing while claiming the right one sat there ready for days.

The project itself names a reason in the release note why such maintenance releases are likely to become more frequent: ever more capable AI models are being deployed to hunt for possible vulnerabilities in open-of reports. Anyone running infrastructure will therefore have to update more often, which makes the question of how you verify an update more important than the question of whether you carried one out

Three habits follow from this, and they cost little time. Pin containers to digests rather than to moving tags. After every update, check the content and not the label. And keep a record of which version with which check value you rolled out when, so that at the next advisory you know within minutes whether it affects you. Anyone unwilling to put that effort into a running server service should honestly consider whether a leaner custody arrangement fits their daily routine better.

Checking your Core Lightning update: what to take away

1. Check the digest today, not the version number. One command, one comparison against the target value from the release note, and the question is answered. If you find in the process that running your own node is becoming too much work, our hardware wallet comparison gives you an overview of the alternatives to pure self-custody via a server.
2. Pull again and restart if the value differs. Pull, check the digest again, swap the container, and only then remove the --offline flag. For everything else you run in software on the node afterwards, the software wallet comparison is worth a look, because the same question of update routes and proof of origin applies there.
3. Build your maintenance around check values. Pin the digest, verify checksums and signatures after every download, document the state. And if you want to top up channels, you will find the routes in our overview of how to buy Bitcoin.

(As of September 15, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)

Primaryct’s repository and the Blockstream project announcement for the release

Transparency note: This article was produced with the assistance of artificial intelligence and reviewed by our editorial team before publication. All figures and claims were checked against the primaryI

Source: cryptoticker.io