Security · Original reporting
25 Fixes Core Lightning Kept Sealed for Two Weeks
The embargo on Core Lightning's emergency release ended on Friday, and the code is now public. This desk read the changelog and the commits. There's a REST crash that needed no login, a BOLT12 message that could make the node read past its memory, and channels that stopped being watched after a reorg. There's still no advisory, no CVE and no severity rating.
For two weeks, Lightning operators running Core Lightning were asked to install an update they couldn't read. Version 26.06.7 shipped as signed binaries on August 28. Its release notes said it fixed "vulnerabilities responsibly reported by a number of sources" and held back the source code for fourteen days, so attackers couldn't diff the patch before the network updated. That note has now been edited: "The embargo has ended. The source for this release was published on 2026-09-11T11:42Z."
Since then the release notes have grown a detailed guide to verifying the release, and still say nothing about what it fixed. The repository lists no published GitHub security advisory. The release carries no CVE identifiers and no severity ratings. The explanation is in the code, so this desk read it: the changelog at the tag, which is dated August 26, and the 59 commits written between August 5 and that date. As of Monday evening, we found no outlet that had published the list.
What the changelog says
The v26.06.7 changelog has nine "Changed" entries and 25 "Fixed" entries. Not all of them are security fixes. One corrects a log message that printed a stack address, and another fixes how an offer's proportional amount is calculated. But the maintainers' own descriptions of several entries leave little doubt about why the source was held.
A REST crash that needed no login. The entry for the clnrest plugin reads: "an unauthenticated user could crash the node with a large request body." Request bodies are now capped at 2 MiB.
A BOLT12 message that read out of bounds. "A crafted BOLT12 message could cause an out-of-bounds read while computing its identifier." The commit explains the mechanism. A helper called tlv_span could return a length computed against a NULL pointer, "close to the full width of size_t." That length went to a hashing function, which then walked memory "until it faults."
A hostname that overran a buffer. Core Lightning built SOCKS5 proxy requests in a fixed 255-byte buffer and never checked the hostname's length. According to the commit message, a host longer than 248 bytes corrupted an adjacent length field, and the proxy socket "received connectd's heap instead of the request." The commit says the hostname could come from a gossiped DNS address, not only from the operator's own configuration.
Feerates nobody bounded. Six fixes deal with fee rates. The changelog says a peer could initiate a splice "at an arbitrarily high feerate." A peer opening a dual-funded channel could "name an arbitrary funding or commitment feerate." The dual-funding commit puts it more bluntly: "a peer could name any feerate and we would sign for it and store it." Core Lightning will no longer propose more than 400 sat/vB on its own. Even with fee limits switched off, it now refuses anything above 4,000 sat/vB.
The 25 "Fixed" entries in v26.06.7, grouped by what they touch
The onchain fixes
The entries closest to user funds involve what happens after a channel closes. Before this release, if a reorg removed a transaction that onchaind was watching, Core Lightning shut the daemon down and never restarted it. The commit message says so plainly: "the channel is unwatched until the next restart: no new claim is proposed, no spend of a remaining output is seen, and it's never resolved."
A second commit changes how a mutual close is recognized. Before, onchaind judged a closing transaction by where its outputs went. Now it checks the transaction's structure. The commit says the goal is that "a revoked commitment whose only output happens to match the peer's recorded shutdown script is no longer classified as a mutual close," and its regression test is named "a revoked commitment paying our shutdown script is still a cheat." A third fix makes the node fulfill an incoming HTLC when it learns the preimage onchain, even if the outgoing side had a failure still in progress. A fourth, in xpay, checks that a fetched BOLT12 invoice asks for the amount the node actually requested. Before, xpay used "the invoice's own figure instead," and the default fee cap scaled with that same figure.
None of these commits says any of this was exploited. In late August, TFTC quoted Core Lightning's Christian Decker saying the project wasn't aware of any vulnerability being actively exploited, and the project hasn't published anything since that changes that. This desk also isn't going to guess which report led to which fix. The dual-funding commit does refer to "the open_channel2 plant named in the advisory," though, so a written advisory exists. It just hasn't been published.
Up to four days without the fix
The embargo also had a gap that the release notes now acknowledge. Between 16:04 UTC on August 28 and September 1, the Docker tags v26.06.7, latest, v26.06.7-vls and latest-vls served images that "reported v26.06.7 on startup but did not contain the fixes in this release." CI had published them automatically from a placeholder tag. TFTC reported the problem on August 31, and CryptoSlate followed. At least one downstream packager was caught: Start9's notes say its StartOS release 26.6.7:1 was affected, and 26.6.7:2 switched to the signed tarballs on September 1. Operators who pulled during that window are told to compare their image digest against the table in the release notes. For Docker users, the version string their node printed told them nothing.
What "verify it yourself" covers
The release notes are candid about how far verification goes. The source archive's hash was in the signed manifest on August 28, so anyone can confirm the code published on September 11 is the code that was signed. The amd64 binaries can be rebuilt, but only with -O3, a flag the project's own build script "cannot pass through." The arm64 tarballs "cannot be reproduced from this tag," because the tooling that built them isn't in the tree. The linux/arm/v7 Docker image "is not covered by any manifest," and none of the images carry provenance or SBOM attestations.
Two more details from the public record. The credits list sixteen reporters. And five of the 59 commits carry a Co-Authored-By: Claude trailer, including the BOLT12 out-of-bounds fix. That's the release that started with a flood of AI-generated bug reports. The fixes don't go into master automatically: on Monday, maintainer Níckolas Goline opened seven pull requests forward-porting what the PRs call a "54-commit series." They were all still open at publication.
One note on our own coverage. This desk's earlier story, last updated September 2, said, citing BeInCrypto, that the fix would ship in CLN 26.09. It had already shipped as 26.06.7 on August 28. That story now carries a correction.
The Take
The embargo was a reasonable call, and on its own narrow terms it seems to have worked: the project has reported no exploitation, and three days after the source went public, this desk could find no one who had even listed the fixes. But an embargo is only half of disclosure. The other half is the moment the project says, in plain words, what was wrong, how bad it was, and who needs to do what. Core Lightning's release notes run to nearly 1,800 words on reproducing and verifying its binaries, and say nothing about what the binaries fix. That leaves operators reading commit messages to learn that an unauthenticated request could crash a node, or that a reorg could leave a channel unwatched. The advisory exists; one of the commits cites it. Now that the code is out, publishing it costs nothing and would answer the question that matters to someone running a node: whether they needed to rush.