The Machines Found Real Bugs: Inside Core Lightning's Embargoed Emergency

Core Lightning, one of the main open-source implementations of Bitcoin's Lightning Network, confirmed on Thursday that multiple vulnerabilities in its software are real — and that it found them in a place nobody wanted to look: the pile of AI-generated bug reports that open-source maintainers have spent two years treating as spam.

The project said it had been working through a high volume of machine-generated Common Vulnerabilities and Exposures submissions and determined that several described genuine flaws. It has not published CVE identifiers, severity ratings, or technical details, and says it knows of no exploitation or losses so far. A fix is coming — but deliberately not immediately.

A patch on a 14-day clock

Rather than shipping details with the fix, the developers are running a coordinated-disclosure embargo: roughly two weeks in which the patched software rolls out while the vulnerability details — and even the fix's source code — stay private, per The Crypto Times. The logic is straightforward: the moment a fix is public, attackers can diff the code and reverse-engineer the bug. The embargo gives node operators a head start. Signed releases come first, so operators can verify the software actually came from the development team before installing it — a detail that matters more than usual in a week when everyone is primed to install an "urgent update."

What operators are actually being told

Here is where the coverage went sideways. Several aggregator headlines told Lightning operators to shut their nodes down immediately. Core Lightning's guidance says close to the opposite: don't fully stop your node. The primary recommendation is to upgrade as releases land. For operators who can't upgrade yet, the fallback is restarting the node with the --offline flag — a mode that stops payments from entering, leaving, or routing through the node while keeping the daemon alive and watching the chain.

The distinction isn't pedantry; it's the difference between safe and sorry. A Lightning node that is fully stopped is blind: if a channel counterparty force-closes with a stale state while you're down, nobody is watching to challenge it. A node in offline mode still follows the blockchain and can respond. "Turn it off" and "take it off the network" are different instructions, and only one of them protects your channel funds.

The AI angle is the story under the story

For two years, open-source security has had an AI-slop problem: language models generate plausible-looking vulnerability reports by the hundred, and drowning maintainers have learned to dismiss them wholesale. The curl project stopped fighting it: in January 2026 it shut down its bug bounty entirely, ended monetary rewards "no matter which severity," and moved reporting off HackerOne to its own disclosure process, after a run of submissions in which, per BleepingComputer, not one described a real vulnerability. Core Lightning's week complicates that reflex from both directions: buried in the slop were real bugs — which means the machines are now finding genuine vulnerabilities in Bitcoin infrastructure, and it means every project that auto-ignores AI reports has to wonder what's sitting in its own trash folder.

That cuts both ways. If AI-assisted auditing found these flaws for the reporters, it can find flaws for attackers who never file a CVE. The window between "machines can find it" and "someone weaponizes it" is exactly what the 14-day embargo is racing against.

Which versions, and how long the dark runs

The advisory's operational content is narrower than the coverage suggested, and worth stating exactly. Every node running CLN 26.04 or earlier is affected. The fix ships in CLN 26.09, slated for release in September, per BeInCrypto. The reports that started this arrived around August 13 — two weeks before the project confirmed publicly that any of them were real.

The embargo lifts the week of September 9, at which point the vulnerability details and the fix's source code both become public. That is the sequence worth watching. Until then, operators are being asked to install a patch whose contents they cannot read, on the word of the maintainers alone — which is precisely why the signed-release step is not a formality. The Defiant put the awkwardness of that position in its headline: operators told to go offline, with no patch published.

As this story was updated on September 2, no CVE identifiers, severity ratings, or technical details had been published, and the project had still reported no known exploitation. Six days of embargo remain.

The trash folder nobody wants to audit

What makes the Core Lightning result uncomfortable is that curl is not an outlier — it is the model. A flagship open-source project with a full-time security-literate maintainer looked at the volume of machine-generated reports, concluded that triaging them was a worse use of finite attention than the bugs they might contain, and closed the intake. That was a defensible engineering decision in January. It is a harder one now that a Bitcoin infrastructure project has gone through the same pile and pulled real flaws out of it.

Neither project is wrong, which is the problem. Triage capacity is the scarce resource, not reports, and no maintainer can read everything. But the two outcomes together describe a gap that has opened quietly across open-source security: the cost of checking has risen faster than the cost of submitting, and the projects most likely to be running on volunteer attention are the ones most likely to close the door. Whatever is behind those doors does not stop existing when the intake shuts.

Related "Pennies": why security leaders think the billion-dollar hacks are the warm-up

These flaws are separate from the remote denial-of-service vulnerabilities Core Lightning disclosed in May and July, which were patched in earlier releases. But the cadence itself is telling: three security cycles in four months for one of Lightning's core implementations, in the same season the industry logged its worst half-year of losses on record.