What happened
On 28 August 2026 the Core Lightning project published
v26.06.7, a point
release carrying "fixes for vulnerabilities responsibly reported by a number of sources".
The signed binaries went out. The source did not: the release notes say that "this embargo
period will last for two weeks" and that "the source code will not be published until 14
days have passed". Two days earlier the maintainers had told operators of
Lightning nodes to upgrade as soon as the release
appeared, or to restart with the --offline flag while they waited, as recorded in
Bitcoin Optech newsletter #420, which
also reported that no active exploitation was known.
What it changes
A patch is a description of the bug. Publishing the diff alongside the binary tells every reader of the repository exactly which check was missing and where, and on a network where your node keeps funds in channels with peers who can open a connection to it directly, the people best placed to use that description are the ones already connected to you. The release notes give the reason plainly: the delay "is designed to reduce the chances of prospective attackers reverse-engineering the fixes and exploiting them before the network can update".
That is a departure from how this project normally works, and it is being made under pressure of volume. The notes attribute the wave of reports to a change in who is looking: "increasingly capable AI models are being used to identify potential vulnerabilities in open-source code, significantly increasing the volume and pace of security reports". The release credits fifteen reporting parties, among them Project Loupe, whose static analysis also turned up a data race in Bitcoin Core this month.
The thing that makes an embargo like this survivable is that it is checkable later. Core Lightning's builds are reproducible, so when the source is published in mid-September anyone can compile it and confirm that what comes out matches the binary that was shipped in August. The trust asked for is temporary and it expires on a date.
What it does not change
Nothing in the release tells you what was wrong. Severity, which versions were exposed, and whether an ordinary node was reachable by the flaw are all still unknown outside the project, so an operator deciding what to do is deciding without the usual facts.
--offline is neither a fix nor a shutdown. It leaves the node running and watching the
chain, so it can still react to a channel closing, while refusing to talk to peers. Payments
in and out stop, and routing stops. That is the trade being offered for the two weeks.
This is one implementation, not the protocol. The same newsletter carries a separate security release of Eclair, and the Lightning specification itself is untouched. A fix in one node implementation says nothing about the others, which is the usual shape of these events: see the splice input LDK began rejecting and the gossip flood LND put a bound on.
Context
Bitcoin Core publishes its fixed vulnerabilities after the fact, on the reasoning that nobody can be forced to upgrade, so an operator who is told nothing cannot judge whether staying on an old version is safe. Core Lightning is applying the other half of the same practice, the part where coordinated disclosure holds the details until the fix is in place, and stretching it to cover the code as well as the write-up.
Both positions accept a cost. One tells attackers what to look for the moment the fix lands. The other asks users to run something they cannot read yet. Which cost is worth paying depends on how quickly a network can be expected to upgrade, and on a Lightning network of always-online nodes holding funds in channels, the maintainers have judged that two weeks of opacity is cheaper than two weeks of a public map.