Blockstream’s Core Lightning team has told node operators to install an embargoed security build or shut their nodes down, after a run of AI-generated vulnerability reports landed on the project during August. The instruction went out in the Core Lightning Discord rather than in a public advisory, and Bitcoin developer and BIP maintainer Mark “Murch” Erhardt confirmed on Stacker News that a CLN maintainer had verified the message as genuine.
No CVE identifier has been published for any of the reported issues. There is no security advisory on corelightning.org, on the Blockstream blog, or in the project’s GitHub security tab. The team said the details of the fixed release will stay under embargo for two weeks, which leaves the vulnerability class, the affected subdaemon, and the severity unknown to everyone outside the maintainers and the original reporters. Operators have been handed a conclusion without the evidence behind it.
The 13 August message to the Core Lightning Discord. Screenshot via Stacker News.
What the Core Lightning Team Told Node Operators
The warning arrived in two parts, ten days apart.
On 13 August 2026, a Blockstream team member posted as @madelinevibes — the account that has signed several recent CLN release tags on GitHub, including v26.06, v26.06.1, and v26.06.2 — told the Discord that Core Lightning had received a number of AI-generated CVE reports from multiple sources over the preceding ten days. A small team, plus outside contributors, was validating and triaging them, and a point release carrying many of the fixes was expected within days.
That plan changed. On 23 August, the same account said the project would skip the ordinary point release and instead publish binaries for a release containing fixes for many of the reported vulnerabilities, with the release details held back for two weeks. The binaries were to ship with the team’s signatures confirming reproducibility. Operators were strongly encouraged to upgrade during the embargo window. For anyone who chose not to, the guidance was blunt: “we recommend taking your node --offline”.
The same message withdrew support for earlier releases, naming v26.04 specifically, and confirmed that the scheduled v26.09 release remains planned for late September.
Which Core Lightning Versions Are Affected
The team has not named a first-affected version, a fixed build number, or a component. Until the embargo lifts, the only safe reading is that every publicly released version should be treated as affected.
| Release | Published | Status |
|---|---|---|
| v26.06.6 | 22 July 2026 | Newest public release. Predates the embargoed fixes. |
| v26.06 / .1 / .2 | June 2026 | Superseded. Predates the embargoed fixes. |
| v26.04 / v26.04.1 | April 2026 | Explicitly no longer supported. |
| v25.12 and older | 2025 and earlier | Unsupported. Treat as affected. |
Check what you are actually running rather than what you think you installed. Node-in-a-box distributions package CLN on their own schedule, so an Umbrel, Start9 or RaspiBlitz box can sit several point releases behind upstream. Run lightning-cli --version on the host and compare it against the table above.
Has Blockstream Published a Patch?
Not on the usual channel. At the time of writing, the newest release listed on the project’s public GitHub releases page is v26.06.6, tagged on 22 July 2026 and still flagged as Latest. The fixed binaries described in the Discord message are not there.
That means operators upgrading during the embargo are collecting a build from the project’s own channels rather than the release page they normally use. Verify the reproducibility signatures the team promised before you run anything, and do not take a CLN binary from a third-party mirror, a forwarded link, or a helpful stranger in a chat group. A security embargo that pushes people to unusual download paths is exactly the condition an attacker would want to exploit.
Disclosure Timeline, and What Is Missing From the Public Record
This is the part worth keeping. The gap between what operators have been told and what has been published anywhere citable is unusually wide, and it is the reason so many node runners only learned about this on 26 August.
| Date | Event |
|---|---|
| 3 Aug 2026 | Boltz suspends Bitcoin, Lightning, and Liquid swaps indefinitely, citing AI-assisted attacks. |
| 4–5 Aug 2026 | Bitcoin Red Team files 4,962 findings across 390 open-source Bitcoin repositories in 27.5 hours. |
| c. 3–13 Aug 2026 | CLN receives AI-generated CVE reports from multiple sources over roughly ten days. |
| 13 Aug 2026 | CLN tells its Discord that a point release is coming within days. |
| 23 Aug 2026 | Plan changes to embargoed binaries. Upgrade-or-go-offline guidance issued. v26.04 dropped. 10 days later. |
| 26 Aug 2026 | Message reposted to Stacker News. Murch confirms with a CLN maintainer, 13 days after the first notice. |
| 27 Aug 2026 | No newer public release, no advisory, no CVE. 14 days after the first notice. |
Set against the artefacts a coordinated disclosure normally leaves behind:
| Expected artefact | Status, 27 August 2026 |
|---|---|
| CVE identifier(s) | None published |
| CVSS score/severity rating | None published |
| GitHub security advisory | None listed |
| Post on corelightning.org or the Blockstream blog | None |
| Newest release on GitHub | v26.06.6, 22 July 2026 |
| Named reporter or research team | Not disclosed |
| Where the guidance actually lives | Core Lightning Discord |
That last row is the complaint driving most of the community reaction. A public service announcement routed through a single invite-only chat server reaches the operators who happen to be in it, and nobody else. Several commenters on the Stacker News thread argued that an exchange, a Lightning service provider or a merchant running CLN in production could have gone the full ten days without hearing anything. Cyber Kendra has not independently verified whether any CLN operator has lost funds, and no such loss has been reported.
Why This Is Hitting Core Lightning Now
Core Lightning is not being singled out. August 2026 has been the worst month on record for Bitcoin’s open-source infrastructure, and the pattern is consistent.
- Coldcard. A firmware random-number-generator flaw was exploited from late July. Galaxy Research confirmed 1,719 BTC stolen, around $111 million, as of 8 August, with a possible ceiling near $130 million.
- Boltz. The non-custodial swap bridge suspended service on 3 August. Its statement described the structural problem plainly: “attackers now iterate faster than a team our size can find and patch”.
- Bitcoin Red Team. Sixteen volunteers, funded with roughly $40,000 of OpenSats-backed AI compute, filed 4,962 findings across 390 repositories in a 27.5-hour sprint on 4–5 August, including 85 rated critical and 635 high.
- BTCPay Server. Merchants were told to update or shut down over an actively exploited flaw that drained funds from merchant-run Lightning nodes, fixed in 2.4.2.
- LND. A separate channel-close flaw was disclosed on 13 August, with the fix landing in 0.21.0 rather than the 0.20.0 cited in the original disclosure.
Core Lightning is absorbing that wave with a smaller team than it had three months ago. Rusty Russell left Blockstream in June after eleven years, having authored 9,762 commits, close to 54 percent of everything in the repository. Whatever the reports turn out to contain, the arithmetic is unfriendly: machine-generated findings arrive at machine speed, and triage still runs at human speed.
The Risk of Taking a Lightning Node Offline
“Just shut it down” sounds like the conservative option. For a Lightning node, it is a trade, not a retreat, and the trade is worth understanding before you make it.
An offline node is not watching the chain. If a channel peer publishes an old, revoked commitment transaction, the penalty response has to be broadcast inside the channel’s to_self_delay window. A node that is powered off cannot do that, and unless you run a watchtower, nothing else will do it for you. Pending HTLCs are the other exposure: forwarded payments that are in flight when the node stops can be lost if the node is still down when their CLTV deadlines pass. Peers may also force-close channels after a long disconnection, converting your balance into on-chain outputs at whatever the fee market looks like that day.
Taken together, offline is a sensible short bridge to an upgrade. It is a poor long-term posture, and it is the wrong choice for a node with large channels, active routing traffic, or in-flight payments unless you have first dealt with those.
What CLN Node Operators Should Do Now
- Upgrade first, offline second. The embargoed build is the outcome the maintainers want. Get it through the project’s own channels — the Core Lightning Discord, the CLN Telegram group, or the c-lightning mailing list — and check the reproducibility signatures before running it.
- Back up before you touch anything. Secure
hsm_secretand theemergency.recoverfile from your Lightning directory. If your node is unrecoverable later,emergencyrecoverplus that file is what asks your peers to force-close so you can sweep funds. - Shut down cleanly. On v26.06 and later, the
gracefulcommand prepares CLN for shutdown rather than pulling the process out from under in-flight state. Use it. - Rotate credentials, not just the binary. This is the lesson from BTCPay Server three weeks ago: stolen access tokens survive a patch. Regenerate runes, refresh clnrest and gRPC certificates, and reissue anything a wallet or plugin uses to reach your node.
- Close the attack surface you control. The RPC socket, clnrest, and gRPC should not be reachable from the open internet. Bind them locally and reach them over Tor, a VPN, or an SSH tunnel.
- Plan for a longer outage. If you intend to stay offline past a few days, cooperatively close channels while your peers are still online rather than letting them force-close on their own terms later.
- Audit before you relax. After upgrading, review recent channel activity, forwarded payments, and on-chain movements for anything you did not initiate.
How This Compares With Past Lightning Security Events
Lightning has had loud incidents before. In late 2022, the developer Burak took a large share of LND nodes out of sync with a single Bitcoin transaction, exploiting a consensus discrepancy between Bitcoin Core and btcd; Lightning Labs shipped an emergency hotfix within hours. In 2023, the “All your mempool are belong to us” disclosure covered CVE-2023-40231 through CVE-2023-40234 and was published in full, on a public mailing list, with working details.
What separates the current Core Lightning situation is not severity, which nobody outside the project can assess yet. It is the absence of a public record. There is no identifier to track, no advisory to link, no severity to triage against, and no channel outside a chat server carrying the instruction. For operators running CLN inside a business, that is a governance problem as much as a security one.
Frequently Asked Questions
Is there a CVE for the Core Lightning vulnerability?
No CVE identifier has been published as of 27 August 2026. The reports that triggered the response were themselves described by the project as AI-generated CVE reports, but no assigned CVE ID, CVSS score, or advisory has appeared publicly.
Which Core Lightning versions are affected?
The project has not named a first-affected version. It has been said that previous releases, including v26.04, will no longer be supported, and the newest public release, v26.06.6 from 22 July 2026, predates the embargoed fixes. Treat every public release as affected until the disclosure lands.
Should I really take my CLN node offline?
Only if you cannot upgrade. The maintainers’ preferred outcome is that you install the fixed build. An offline node cannot respond to a revoked commitment transaction or protect in-flight HTLCs, so shutting down is a short bridge to upgrading rather than a safe resting state.
Are my funds at risk if I run Core Lightning?
Nobody outside the project can answer that yet, which is the core problem. No CLN operator has publicly reported a loss connected to these reports, and Cyber Kendra has not verified any. The maintainers’ own framing — upgrade or go offline — indicates they consider the risk material.
Does this affect LND, Eclair, or LDK nodes?
No. This guidance applies to Core Lightning only. LND had a separate channel-close disclosure on 13 August 2026 with its fix in 0.21.0, and operators of other implementations should follow their own projects’ advisories.
When will the full details be published?
Two weeks after the fixed binaries are made available, per the project’s own statement. On the stated schedule, full disclosure is placed ahead of the v26.09 release, which remains planned for late September 2026.
Where do I get the fixed binaries?
Through the project’s official channels rather than the GitHub releases page, which had not been updated at the time of writing. Verify the team’s reproducibility signatures, and do not accept a build passed to you by a third party.