- Core Lightning published the release fixing several reported vulnerabilities on 28 August, after telling operators to upgrade or run their nodes offline. Maintainers now say four Docker image tags served unpatched binaries for several days while reporting the new version number at startup, so some operators who think they upgraded haven’t.
- The flaws came out of AI-generated vulnerability reports that developers checked and confirmed were genuine. The technical details are still under embargo, with disclosure planned for 11 September.
- Nobody has reported an exploit or any lost funds. This is a precaution, not a theft.
A warning went out on 23 August to a fairly small group of people: those running Core Lightning, one of the main pieces of software behind Bitcoin’s fast-payments layer. Upgrade, or take your node off the internet. The fix arrived five days later, and for some operators it didn’t actually arrive at all.
What Lightning is, briefly
Bitcoin’s main chain is slow and deliberately so: every transaction is checked by everyone, which caps how many can happen. Lightning sits on top of it. Two parties lock some bitcoin into a shared channel, then pay each other back and forth off-chain as often as they like, and only settle the final balance on the later. It’s what makes buying a coffee in bitcoin plausible rather than absurd.
Core Lightning, maintained by Blockstream, is one of a handful of implementations of that system. Someone has to run the nodes that route those payments, and those operators are who the notice was addressed to.
What the developers actually said
The message, posted to the Bitcoin forum Stacker News, urged operators to upgrade to a release fixing multiple reported vulnerabilities. Operators who don’t want to upgrade were told to run their nodes offline instead. The team said it would keep the technical details under embargo for roughly a fortnight, and would attach team signatures to the binaries so operators can check the packages came through the normal release process.
That release, v26.06.7, went out on 28 August. The problem is what happened to it on the way to the people who needed it.
According to the maintainers’ updated notice, reported by CryptoSlate, four Docker image tags served images without the release’s fixes: v26.06.7, latest, v26.06.7-vls and latest-vls. The window given runs from 28 August at 16:04 UTC to 1 September, with no precise end time. An automated build process had published the images from a placeholder tag. Maintainers say they have since replaced them and removed every tag’s reference to the incorrect manifests.
The awkward part for anyone who pulled one of those images is that it looks fine. A faulty image reports v26.06.7 at startup exactly as a patched one does, so the version number tells an operator nothing. The check is the image digest: compare it against the corrected image, and if it differs, download again.
The accounts of this notice have moved around a fair bit. CryptoSlate pointed operators at new binaries to install; Decrypt described the project as preparing fixes; The Defiant reported last week that no release had been published for operators to install. The maintainers’ own updated notice now says a release exists and that the Docker route to it was broken for several days, which is the version we’re going with. Anyone running a node should go by whatever the project’s own release page says rather than by any of the write-ups, including this one.
Where the vulnerabilities came from is now on the record. Decrypt reports that they were first raised in AI-generated vulnerability reports, and that the developers confirmed several of those reports were accurate before putting the warning out. A machine found the problem and a person checked it was real, which is the part that turned a pile of automated findings into an urgent notice.
The signing matters more than it sounds. Core Lightning’s documented release process uses signed tags, signed checksums and reproducible builds, which lets an operator confirm a download is the genuine article rather than something an attacker slipped in during a moment of panic. That is now the practical work in front of anyone who upgraded in the past fortnight, because “install this urgently” is exactly the message a scammer would also send, and a week of official images that were quietly wrong makes fake downloads harder to spot rather than easier.
We haven’t been able to read the original Stacker News post directly. This account comes from CryptoSlate’s, Decrypt’s and The Defiant’s write-ups of it and of the maintainers’ subsequent notice, and where they differ we’ve stuck to the narrower version.
Why nobody will tell operators what the bug is
Withholding details during a disclosure window is standard practice across software, not something peculiar to Bitcoin. If you publish how a vulnerability works before most people have patched, you have handed a working attack to anyone who wants it. The embargo buys time for the fix to spread.
The awkwardness here is specific to Bitcoin, though. The whole appeal of running your own node is that you don’t have to take anyone’s word for anything: you verify the rules yourself. During a live security incident that breaks down. Operators can’t inspect the evidence, can’t work out the exploit mechanism from what’s public, and can’t tell whether their particular node configuration is exposed at all. Knowing that the reports were machine-generated and then human-verified tells them something about where the warning came from, but not what the bugs do. They’re still being asked to trust the maintainers, which is the one thing the software is designed to avoid.
The Docker mix-up is the same problem one layer down. An operator who can’t see the bug also can’t tell from the inside whether the fix reached them, and the one signal they’d normally reach for, the version the software prints when it starts, was wrong for several days. Checking a digest against a published one is a small task. Knowing you need to is the hard bit, and that depends entirely on reading a notice you may never have seen.
AI is finding bugs faster than humans can sort through them
The Core Lightning warning is now the clearest example of this itself. The findings arrived from an automated review, and the maintainers’ work was deciding which of them held up.
The same week, the Bitcoin privacy wallet Sparrow shipped version 2.5.4. Developer Craig Raw said most of the fixes in it came out of an AI-assisted code review, and that none of them looked likely to put users’ funds at risk.
Two projects, one busy week, both patching off the back of machine-generated findings. That’s a pattern worth noticing rather than a coincidence, and it cuts both ways. Automated review genuinely does surface real problems in code that volunteers wrote years ago, and Core Lightning has now confirmed that several of the reports sent to it were correct. It also produces volume, and open-source maintainers are the bottleneck: a report has to be read, reproduced and judged by a person before anyone knows whether it’s serious. Nobody has said how many reports arrived in total, so CryptoSlate’s framing of an “onslaught” remains its own characterisation rather than a figure anyone has published.
This is also the second Lightning security scare in a month, which will be doing nothing for the confidence of people who were already unsure about running their own infrastructure. Our guide to self-custody covers the trade-off between holding your own keys and letting someone else carry the operational risk.
What to watch
Whether the corrected images actually reach people. The release exists and the bad tags have been replaced, so the open question is how many operators pulled an image during that window, never saw the follow-up notice, and are sitting on an unpatched node that reports itself as patched. Nobody outside the project can count that from here.
Then the disclosure, planned for 11 September, two weeks after the release went out. We know where the reports came from and that developers judged several of them accurate. What’s still missing is what the bugs actually do and how severe they are, and that’s the gap the disclosure has to fill. If the flaws turn out to be minor, expect a row about how the warning was handled. If they don’t, the week of images that shipped without the fixes becomes the more serious half of the story.
Expect scam messages pointing at fake downloads for as long as operators are being told to re-check what they installed. And watch whether routing capacity on the network dips, either from nodes going offline or from operators pulling them down to redo the upgrade. Payments failing or getting slower would be the first sign this reached ordinary users at all. As things stand there’s no report of an exploit, no report of stolen funds, and no figure attached to either.