Decent Newsroom
Sign In

Two Days to Fix, Six Months to Tell

By Roger October 24, 2026
Bitcoin Core just stopped hiding vulnerabilities that a single prompt can rediscover. The disclosure economy it replaced was priced on a scarcity of knowledge that no longer exists - and sixteen months of CVE data say the scarcity is gone.
Two Days to Fix, Six Months to Tell

Two Days to Fix, Six Months to Tell

Bitcoin Core just stopped hiding bugs that a prompt can find. The disclosure economy it replaced was priced on a scarcity that no longer exists.

On 23 April 2026 a researcher reported a bug to the Core Lightning maintainers. A peer could crash any node by sending a single channel announcement that named the same node as both of its endpoints. The routing code never checked that the two node IDs differ, so the same node was inserted twice into the map, a no-duplicates assertion tripped, and the daemon aborted, taking the whole node down with it.

What follows the crash is the vicious part. The announcement is written to disk before it is loaded into the routing graph, so every restart reads it back and aborts again. Upgrading does not clear it. The node stays offline until an operator deletes the record by hand, and the attacker can resend the same message for as long as the funding output behind it remains unspent.

The fix was merged one day after the report: a check that node_id_1 must be lexicographically smaller than node_id_2. One comparison. Core Lightning v26.04.1 carried it into the world on 25 April 2026.

Word reached the public on 24 October 2026. Between the fix and the telling lay 182 days.

Core Lightning disclosure timeline: 415 days vulnerable, 182 days of withheld details

That gap is not negligence. It is textbook coordinated disclosure, the arrangement that has governed software security for two decades, and it is being dismantled right now from the inside by the people who wrote it.

The rule change nobody argued about for a decade

On 22 October 2026 Bitcoin Core merged a change to its vulnerability disclosure policy. It was authored on 16 October by Chaincode Labs developer Antoine Poinsot, announced on the Bitcoin Development Mailing List the same week, and translated into Japanese the following day. The live policy page now contains a sentence that did not exist a week earlier:

“The public disclosure timeline will depend on whether we classify a reported vulnerability as easily discoverable. This classification applies to vulnerabilities that can be discovered with minimal effort, such as through a simple LLM prompt.”

What follows from that classification is the real change. For vulnerabilities flagged as easily discoverable, the project will backport a fix to every maintained major version, cut point releases as fast as it can, and publish a security advisory at the same moment the fixed software ships. No embargo. For everything else, the old calendar still applies: low-severity bugs become public two weeks after the major release that fixes them, while medium and high severity wait until two weeks after the last affected release reaches end of life, which is roughly a year after a fix first shipped in a major version.

Read the two schedules side by side and you see what was actually given up. A high-severity memory-corruption bug could be held for twelve months while operators migrated at their own pace. Now, if a model can rediscover it, the window between “fix exists” and “everyone knows” collapses to zero, and so does the testing time before a release reaches users. Poinsot acknowledged that trade in the proposal. He wrote that for bugs that are easy to rediscover, “the embargo period achieves little but it delays the availability of a fixed release.”

His stated reason is the one that matters: “We recently experienced an increase in the number of reports for security vulnerabilities that can be easily (re-)discovered. This is largely due to LLMs drastically reducing the bar to find certain classes of issues or identify covert fixes.”

Note the second half of that sentence. Not just finding the bug: identifying covert fixes.

An embargo is a bet on the price of rediscovery

Strip the ceremony away and coordinated disclosure is an economic trade, not a moral one. A maintainer who learns about a bug holds two assets: the knowledge and the patch. The patch protects everyone who installs it. The knowledge, if withheld, keeps the bug rare. The embargo is the period in which the project tries to move as many operators as possible from “vulnerable and ignorant” to “patched”, before the knowledge becomes common.

That trade only clears if knowledge stays expensive. The whole justification for waiting is the assumption that an attacker who is not told will not find out on his own within the embargo window. Twelve months of secrecy was a reasonable bet when finding a subtle assertion bug required a specialist with a month to spare.

Bitcoin Core’s own numbers make the collapse visible. In late July a volunteer group of sixteen developers, the Bitcoin Red Team, ran AI models across 390 bitcoin repositories in about a day and logged 4,962 findings, 85 of them rated critical, as reported by Bitcoin Magazine. That is 310 findings per developer per day, and a critical rate of 1.7 percent. Eighty-five critical findings is not a queue any maintainer team absorbs in a day. It is a backlog that has to be triaged by hand, one report at a time, and it arrived in a single afternoon.

The consequence is arithmetic. When rediscovery is cheap, an embargo no longer denies the attacker anything he cannot obtain himself; it only denies the defender the patch. Secrecy stops being a shield and becomes a delay with a cost attached. Bitcoin Core did not change its policy because it stopped believing in coordinated disclosure. It changed policy because, for one specific class of bug, the coordination had lost its counterparty.

The measurement: 15,074

The claim that finding has become cheap is testable, and not only inside Bitcoin.

Using the National Vulnerability Database’s public API, I pulled sixteen consecutive months of published CVE counts (own queries, run 24 October 2026). From June 2025 through April 2026 the series hovers between 3,116 and 6,304 a month and shows no trend worth naming: 3,799 in June 2025, 4,537 in September 2025, 5,643 in December 2025, 5,885 in April 2026. Then it stops hovering. May 2026 comes in at 6,985, June at 8,001, July at 9,919, August at 12,719, September at 15,074. Six consecutive monthly records, 2.56 times the April figure in five months, 3.3 times the same month a year earlier.

The timing deserves a second look, because it does not fit the tidy story. The inflection begins in May 2026, two months before the Bitcoin Red Team ran its single-day sweep in late July. The Red Team was not the cause of the wave. It was one visible crest of a shift that was already moving upstream, in tooling anyone could rent by the hour.

Published CVEs per month, June 2025 to September 2026

A published CVE is not the same thing as a vulnerability found, and I want to be exact about the limits of that number. Publication counts include scanner output, duplicate filings from competing CNAs, and entries for products nobody runs. A jump this steep is partly a measurement artefact of the reporting pipeline itself: when finding is cheap, filing is cheap too. But the direction is not ambiguous, and it is corroborated by what practitioners wrote in the same forty-eight hours.

The AINews roundup at Latent Space called the stretch “Black October”, and the list it compiled is worth reading slowly. An unauthenticated remote code execution in PHP, publicly nicknamed PHP2Shell. A CVSS 10.0 flaw in GitLab affecting releases back to 2014, patched in 19.5.1. A Brotli decoder RCE in Node.js. A certificate authority, eMudhra, whose keys were reportedly so weak that one of them was the number four, cracked by a single prompt, with the company now exiting the CA business. A password stealer shipped inside LiteLLM 1.107.0. A breach at Zeabur that exposed 321,810 accounts. Quest Diagnostics, which serves roughly half of US hospitals and physicians, reporting exposed patient data. And Microsoft attributing a supply-chain compromise to a China-aligned group that ran an open agentic pentesting framework against more than 2,250 Microsoft 365 tenants at around 2,900 sign-in attempts per minute.

This is not a list of AI findings. It is a list of what a defender’s queue looks like when the cost of producing candidates falls through the floor. Both statements are true at once: more real bugs are surfacing, and more noise is surfacing with them. Bitcoin Core’s response is instructive precisely because it does not pretend otherwise. The new category is narrow, it requires human triage to be applied, and it explicitly leaves critical bugs, the ones that could inflate supply or split the chain, outside the standard policy entirely, to be handled case by case.

What the attack actually costs

The Core Lightning disclosure is a good place to put a price on all this, because the attack is unusually clean.

To trigger it, an attacker needs an unspent 2-of-2 pay-to-witness-script-hash output that he controls, six confirmations deep, plus an ordinary peer connection. The announcement must carry four valid signatures, which he can produce because he holds every key involved. Nothing is spoofed. The message is well-formed; it is only self-referential. The node accepts it, stores it, and dies.

My own calculation of the on-chain cost: funding a 2-of-2 P2WSH output takes roughly 110 to 120 virtual bytes, and spending it later takes about 140, for something near 260 vB for the round trip. At 1 sat/vB, the rate the mempool was quoting when I checked on the morning of 24 October 2026, that is 260 satoshis. With bitcoin at $80,689 (own reading of the market feed that morning), it comes to about 21 cents. At 100 sat/vB, a fee level that has occurred repeatedly in the last two years, the same attack costs about $21. The capital locked inside the output can sit at the dust threshold, 330 satoshis, currently 27 cents.

Twenty-one cents, once, and then the message can be replayed indefinitely while the output stays unspent. For that, an operator loses the ability to watch the chain, which means missing a revoked commitment broadcast or an HTLC that must be claimed before its timelock expires. The cost of the attack is denominated in cents. The cost of the defence is denominated in channel balances.

Cost of the attack in dollars at different mempool fee rates

A second, colder lesson sits in the timeline. The bug entered the codebase in v25.02, released on 6 March 2025, when the node table was changed to reject duplicates. The fix landed on 25 April 2026. That is 415 days in which any node running a maintained release was one gossip message away from a persistent, restart-proof crash, and the public record of it only opened 182 days after the patch was already downloadable.

Patch fast is not a strategy, it is a hope

Here is the part that the new policy has to live with, and it is not comfortable.

Core Lightning’s own advisory ends with a line that reads like a warning to the policy’s authors: “Validate untrusted input before persisting it. A message that crashes the node after it is stored is reloaded, and crashes it again, on every restart.” The same logic applies to the patch-first doctrine. If a bug can corrupt persisted state, then the patch only protects nodes that were never hit. An operator who upgrades the day of the release, the exact behaviour the new policy is designed to reward, still has to know that upgrading is not enough and that a manual deletion may be required. Speed of patching is necessary, not sufficient.

The second uncomfortable implication is the one Riard raised and lost. Riard wanted the option to ship a fix with no advisory at all, saying nothing, letting the diff speak to whoever reads diffs. Poinsot declined, arguing that warning users without giving them details “could create more risk unnecessarily” by pushing people who were never affected into a rushed migration. That is a real dilemma and it has no clean answer: publish nothing and the curious attacker diffs the point release; publish something and the worried operator migrates in a hurry, possibly onto a release with three days of testing.

The strongest counter-case: slow operators are not a bug

The old embargo existed for a reason that has not disappeared: node operators are slow. Bitcoin Core’s own schedule assumed a year of migration time for medium and high severity issues because that is how long operators actually take. Remove the year and you have not made anyone faster; you have only removed the buffer that absorbed their slowness. If a rushed point release introduces a regression, the project will have traded an exotic remote crash for a consensus failure, and that trade is much worse. Poinsot’s answer is that the model found the bug in the first place, so the model can also be pointed at the fix. That is plausible. It is not yet demonstrated, and nobody should pretend it is.

One genuinely symmetric force runs through the whole picture, and it is easy to miss. The Core Lightning bug was not found by a person reading code. It was found by a gossip state-machine fuzz target that feeds the daemon valid and malformed messages and simulates chain lookup, and that target was proposed upstream afterwards. Cheap discovery cuts both ways. The difference between attacker and defender is not who can find the bug. It is who already has the patch.

Why this bites Bitcoin harder than most software

A bug in a web application is fixed by a vendor pushing an update to machines nobody administers. A bug in Bitcoin Core or Core Lightning is fixed by convincing thousands of independent operators to recompile or upgrade, on their own schedule, with their own risk assessment. There is no push channel. This is a feature, not a defect, and it is exactly what makes the old disclosure model load-bearing for Bitcoin in a way it never was for a normal codebase.

Poinsot’s change acknowledges something most of the industry still avoids saying out loud: for a class of bugs, the network’s security no longer depends on keeping secrets. It depends on the distribution of versions. The attack surface has migrated from the code to the social layer, into the question of who runs what, and how long they take to move.

October produced a different, unrelated reminder of what it looks like when an estimate breaks. Morgan Stanley revised its US data-centre power demand model upward by 43 percent in a single cycle, from 68 GW to 97 GW through 2028, leaving a net shortfall of about 32 GW even after crediting behind-the-meter generation and fuel cells, as TFTC reported. Nvidia’s CFO put supply at roughly 70 percent of demand. Two different domains, one pattern: the number that was good enough last quarter is now wrong by a factor, and every plan built on it has to be rebuilt. An estimate that fails by 43 percent is not a forecast error. It is a change of regime.

The capability is about to be free

One more fact closes the loop, and it is the reason I do not think October 2026 will look like a peak.

On 23 October, Moonshot released Kimi K3.1 Pro: a mixture-of-experts model with 2.8 trillion total parameters and 104 billion active, a one-million-token context, and an independent Artificial Analysis score of 55. For scale, Claude Opus 5.5 scored 58, and Claude Fable 5.1, GPT-6 Astra and Gemini 4 Argon all scored 53. The API costs $2 per million input tokens and $10 per million output, which is half the price of Opus 5.5 in Simon Willison’s comparison. And Moonshot has promised full model weights by 4 November 2026.

Put those two facts together. In April, “an LLM can find this class of bug” meant a frontier API at frontier prices, gated behind a provider that could rate-limit, refuse, or log. By November, the capability that Poinsot cited as the reason for his policy change is a downloadable weight file that anyone can run on rented compute, with no gatekeeper to appeal to. Regulators are already moving in the opposite direction, with the US restricting DeepSeek in federal procurement and China’s MOFCOM floating pre-approval for frontier models shared internationally. Neither can reach a file that is already on ten thousand disks.

The direction of travel is therefore unambiguous. The marginal cost of rediscovering a bug is heading to zero and will stay there. Every disclosure policy on earth is now a policy about a world where the answer to “could someone else find this?” is yes, probably this afternoon.

What follows

Three things, in order of how soon they will matter.

The first is that upgrade lag becomes the dominant security variable for anyone running a node, and it is not a variable the embargo can buy back. Operators should plan for a world where a fix and its advisory arrive on the same day, which means having a rollback path, a staging node, and a habit of reading release notes that mention “gossip” or “validation” without explanation.

The second is that boundary validation is cheap and neglect of it is not. Core Lightning’s fix is a single comparison. The miss was a single assumption, that a sender had already applied an ordering rule the receiver never checked. In a network where a malformed message can be persisted and then replayed against every restart, the correct posture is to distrust anything that is stored before it is proven harmless. Most of the serious bugs of this decade will be found in that gap between parsing and persistence.

The third is that “patch fast” must stop being the whole answer. Against state-corrupting bugs, patching helps only the nodes that were never hit. Against consensus bugs, patching too fast can be the injury. The mature version is not speed, it is a ranked plan: what must be backported instantly, what can wait for testing, and what has to be handled by humans on a phone call.

Bitcoin Core’s maintainers made a judgment call this week that will look either prescient or reckless, and the evidence will not be in for a year. What can be said with certainty is that they were honest about the reason. The embargo was never a wall around knowledge. It was a toll booth on it, and the toll has just been waived. From here, the network is defended by how fast it moves, not by what it knows that others do not.

What I could not verify

Four limits on the above, stated plainly.

The Red Team figures, 390 repositories and 4,962 findings in about a day, come from a single published account. I did not see the underlying report list, so the 1.7 percent critical rate should be read as an order of magnitude, not a coefficient.

Nobody knows how many Core Lightning nodes are still on an affected release. Lightning has no reliable public census of software versions, so the exposure window I measured from release dates is a property of the code, not a count of victims.

My 260 vB figure is a calculation from standard script and witness sizes, not a transaction I broadcast. Treat it as the right order of cost, not the exact bill.

And the claim that model-assisted review substitutes for embargo time is, at this point, a hope with a plausible mechanism attached. It has not been demonstrated on a consensus codebase under deadline, and the first time it fails it will fail expensively.

Sources

Write a comment