AI Wrote the Bug Reports. The Fix Was 'Don't Turn It Off.'

AI Wrote the Bug Reports. The Fix Was 'Don't Turn It Off.'

7 min read

The vulnerability reports were AI-generated, and everyone assumed that meant they were noise. Then Core Lightning’s maintainers — a small team maintaining one of the two main implementations of Bitcoin’s Lightning Network — told their node operators to take their nodes offline, and the reason they gave was that several of those AI-generated reports turned out to be real.

The uncomfortable part isn’t the bugs. It’s what the advisory asked operators to do, and how badly the public read it wrong. On Wednesday, the pseudonymous Cashu developer Calle amplified the warning with a sharper framing than the maintainers’ own words: “shut down CLN Lightning nodes right NOW.” The maintainers’ actual instruction said the opposite. A node you switch off stops watching the blockchain, and a Lightning node that isn’t watching the chain cannot defend the bitcoin locked in its channels. The correct defensive move was to keep the machine running and only stop routing payments.

What actually happened

Core Lightning (CLN) is a Lightning Network implementation maintained by Blockstream with outside contributors. The Lightning Network lets people send bitcoin instantly and cheaply by locking funds into two-party payment channels and updating balances off-chain, settling to the Bitcoin blockchain only when a channel closes. As of an Aug. 20 snapshot, the network carried 375,019,291,916 sats — roughly 3,750 BTC, or about $294 million at prevailing prices — across 33,101 channels and 16,420 nodes, per mempool.space.

On Aug. 13, the project’s own account posted what would become the throughline of the whole incident:

“Like many open source Bitcoin projects, CLN has received a number of AI-generated CVE reports from multiple sources over the past 10 days. Our small team, together with several invaluable open source contributors, has been working intensively to validate and triage these reports and develop fixes where needed.”

Thirteen days later, on Sunday Aug. 26, a message went out in the Core Lightning Discord and was reproduced on stacker.news Wednesday. It contained three instructions that together describe a novel kind of security emergency:

  1. The team would publish signed binaries carrying fixes for “many of the reported vulnerabilities,” but hold back what they fix — “the details of the release will remain under embargo for two weeks.”
  2. “If you choose not to upgrade, we recommend taking your node --offline.”
  3. “Given the known risks, we will not support previous releases, including 26.04.”

Note what is missing. No CVE identifiers. No description of what the vulnerabilities let an attacker do. No count of how many are being fixed. No statement on whether any have been exploited. As of Wednesday afternoon, the project’s GitHub security advisories page listed none, and the most recent tagged release was still v26.06.6 from July 22. Operators were being asked to act on trust, with no public description of what they were defending against.

Why “offline” doesn’t mean “off”

The instruction that got mangled in transit is the whole point, technically. Calle’s amplification said shut down. The maintainers said don’t — and they said it again later, explicitly, after the shutdown framing spread. Here is the mechanism that makes the difference:

A Lightning channel is a two-of-two arrangement where each side holds a signed transaction state. Whoever closes the channel publishes a state to the blockchain and gets paid per that state. The security of your funds rests on a single guarantee: if your counterparty tries to close using an old state that pays them more than they’re owed, you have a window in which to spot it and publish the latest state (a “justice” transaction) that penalizes them instead.

That window only exists if you’re online. A node that has been powered off cannot see the counterparty’s stale close, cannot respond on-chain, and loses the ability to defend its side of the channel. A node restarted with --offline drops all peer connections — nothing can be sent, received, or routed through it — but the daemon keeps running and keeps watching the chain. It is still blind to new payments, but it is not blind to a cheating close.

So the mitigation is a precise surgical cut, not a panic button: stop routing, keep watching. The maintainers chose it because, against a Lightning-specific vulnerability, availability is the defense. Powering off converts a vulnerability you haven’t patched yet into an immediate, permanent loss you can’t contest.

The triage crisis underneath

The story’s second layer is about the maintainers, not the nodes. A “flood” of AI-generated CVE reports arrived “from multiple sources” — the project does not name them, though the Bitcoin Red Team, a volunteer group of 16 researchers running AI-assisted audits across Bitcoin’s open-source stack, reported on Aug. 5 that it had filed 4,962 findings across 390 projects in 27.5 hours, including 85 critical and 635 high-severity issues.

That is the shape of the new problem. Bug discovery has become nearly free and nearly infinite — an AI pass over a repo produces more candidate findings in an afternoon than a maintainer can read in a month. What hasn’t scaled is triage: deciding which of those candidates is a real vulnerability with an actual attack path, and which is a plausible-sounding hallucination. The maintainers’ own framing — “validate and triage” — is the giveaway. They are not hunting for bugs anymore. They are spending their scarce hours sorting a torrent of machine-generated claims to find the few that matter, because an attacker only needs one real bug, while the maintainer has to verify everything.

The two-week source embargo is the direct consequence. Releasing patched binaries first, with source held back, is a deliberate anti-reverse-engineering control: it gives operators time to upgrade before attackers can diff the changes and reconstruct the vulnerability. In a world where attackers iterate faster than defenders can patch — the exact language the swap bridge Boltz used when it halted service on Aug. 3 — the diff is the exploit kit, and embargoing it is now a load-bearing security primitive.

The wider signal

Core Lightning is the fourth Bitcoin infrastructure alarm in four weeks, and they share a common thread. A 2021 Coldcard firmware bug that routed seed generation to a weak software randomizer has drained roughly $114 million since July 30. Boltz halted indefinitely on Aug. 3, citing AI-assisted attacks that “iterate faster than a team our size can find and patch.” BTCPay Server told merchants on Aug. 7 to update or shut down over an actively exploited flaw, and Lightning nodes were swept overnight. Now CLN. In parallel, a group including Coinbase, Block, BitGo, Blockstream, and the Bitcoin Policy Institute asked AI labs for early access to their strongest models, arguing that Bitcoin developers were being locked out of programs attackers could reach anyway.

The Denny Sentinel lens on this is not “AI found bugs, so we should be scared.” It is that the control loop broke in a specific, instructive way. Discovery is no longer the constraint; verification is. The scarce resource shifted from “finding the vulnerability” to “knowing which report is true before the attacker does,” and every part of the response — the embargo, the signed binaries, the --offline guidance, the withdrawn support for old releases — is a defense of that new bottleneck, not of the old one.

For anyone running infrastructure that an AI-assisted attacker might point a scanner at, the takeaways are concrete:

  1. Availability is sometimes the security control. Before you tell operators to “shut it down,” understand whether staying up is what lets them defend themselves. The instinct to power everything off is a cloud-era reflex that does not transfer to systems with on-chain penalty mechanisms.
  2. Triage capacity is now the thing to budget for. If your project is public and important, assume a flood of AI-generated reports is coming, and that a meaningful fraction will be real. A triage pipeline — with a human or verifier in the loop that can distinguish a real finding from a plausible one — matters more than any single scanner.
  3. An embargoed diff is a real mitigation. Releasing binaries before source, with reproducible-build signatures, buys operators time. It is not secrecy for its own sake; it is the difference between an attacker studying a patch and an attacker studying a live target.

The bug reports were machine-generated, and the vulnerabilities were real. The interesting part isn’t that the AI found them. It’s that the moment it did, the scarce resource stopped being the finding — and became the decision about which finding to believe.

Sources

Keep reading

It Validated Every Claim and Never Checked the Signature The Weights Stopped Being the Model The AI Triage Called It 'Not a Bug.' It Was a Chrome RCE.