Key takeaways
- Bitcoin Core revised its vulnerability disclosure policy on 23 October 2026, adding a triage label for bugs that are 'easily discoverable' - findable with minimal effort, such as a simple LLM prompt.
- Flaws in that category are patched as quickly as possible across every maintained major release, with the security advisory published at the same time the fix ships.
- The existing timelines are unchanged: low severity two weeks after a fixed major release, medium and high two weeks after the last affected release reaches end of life.
- Critical bugs - coin theft, inflation, permanent chain splits - remain outside the standard policy and are handled case by case.
- Developer Antoine Poinsot's argument is that a long embargo offers little protection when rediscovery is cheap. The honest cost is that faster shipping means less testing before code reaches users.
Bitcoin Core changed its vulnerability disclosure policy today. The practical change is small and the reasoning behind it is not, because it concedes something about security practice generally that has been true for a while and mostly unsaid.
What an embargo is actually buying
Responsible disclosure works on a trade. A researcher finds a flaw, tells the maintainers privately, and agrees not to publish for a period. The maintainers write a fix, test it properly, ship it, and give users time to update before details become public.
That trade rests on one assumption, and it is almost never stated out loud: during the embargo, the people who know about the bug are the only people who know about it.
Secrecy is the asset being purchased with the delay. If secrecy holds, the delay buys safety — a properly tested fix, distributed before anyone hostile learns where to look. If secrecy does not hold, the delay buys the opposite. It becomes a period in which the defenders know about an unfixed flaw, the attackers also know, and only the defenders are obliged to keep quiet.
What changed
Triage can now attach a label: easily discoverable, meaning a flaw that can be found "with minimal effort, such as through a simple LLM prompt".
Bugs in that category get a different process. They are patched as fast as possible across every maintained major release, and the advisory is published at the same moment the fix ships rather than weeks later.
Everything else stays. Low-severity flaws are still disclosed two weeks after a fixed major release. Medium and high still wait until two weeks after the last affected release reaches end of life. Critical bugs — coin theft, inflation, permanent chain splits — remain outside the standard policy and are handled case by case.
So this is not a loosening of discipline. It is a narrow carve-out for a specific condition.
The elegant part is where they put the label
This is the detail I think is genuinely clever and is getting no attention.
They did not redefine severity. A bug that is easy to rediscover has not become more damaging — the harm it causes if exploited is exactly what it was. What changed is an entirely separate property: how long secrecy can be expected to hold.
Most security triage collapses those two things into a single severity score, which then drives the timeline. Splitting them is more honest, because they are genuinely independent. A low-severity bug that any model can surface in one prompt may warrant shipping faster than a high-severity one that took a specialist eighteen months to find.
Severity tells you what happens if someone exploits it. Discoverability tells you how likely someone already has. Only the second one should be driving how long you sit on it, and almost nobody's policy separates them.
Why this follows from something we covered
Two weeks ago we wrote about an AI model finding a decade-old bug nobody else had. At the time the interesting part was the capability itself.
This is the institutional consequence, and it arrived faster than I expected. If a model can find a decade-old flaw that survived a decade of expert review, then the premise that your researcher is the only person who could have found your bug is no longer safe by default. It has to be assessed per bug.
That reassessment is what the new label is. Not a prediction about AI — a procedural admission that rediscovery cost is now a variable rather than a constant.
The scale behind it is worth noting. One review cited alongside the change identified 4,962 potential flaws across 390 Bitcoin-related projects, 85 of them critical. Treat that figure carefully — automated scanning produces large numbers and a "potential flaw" is not a confirmed one, as anyone who has triaged a scanner report knows. But the direction is not ambiguous.
The cost, stated plainly
Coverage of this is broadly positive and I think it is largely right, but there is a trade being made and it deserves naming rather than burying.
Shipping a fix faster means testing it less. Bitcoin Core's release process is deliberately slow because the software settles billions of dollars and a bad patch can cause the exact chain-level damage the policy exists to prevent. Compressing the window between "we have a fix" and "users are running it" reduces the time available to discover that the fix itself is broken.
That is a real risk, accepted knowingly. The judgement is that for bugs anyone can rediscover cheaply, a slightly-less-tested fix shipped now beats a well-tested fix shipped after the flaw has been independently found by somebody who did not report it.
I find that judgement persuasive. I would still rather read it as a trade-off than as an unambiguous improvement, because the people who will carry the cost if a rushed patch goes wrong are node operators, not the policy's authors.
What changes if you run a node
One practical consequence that is easy to miss: under the old timeline, an advisory arriving meant the fix had been available for weeks and you were probably already running it. Under the new one, for this category of bug, the advisory and the patch arrive together.
That inverts the urgency. A published advisory used to be mostly historical — a record of something already handled. For an "easily discoverable" flaw it is now live information, describing a weakness that is fixed in code but not yet fixed on your machine. The gap between the advisory appearing and your node restarting is the whole exposure.
Which means the people who skim release notes monthly are now in a different risk position from the people who track them the day they appear, in a way they were not before. Nothing in the policy obliges anyone to change their habits. The reasoning behind it rather strongly suggests they should.
What this means beyond Bitcoin
Nothing here is Bitcoin-specific. Every project with a disclosure policy — every browser, every operating system, every bank's internal process — is running on the same embargo assumption, and most have not revisited it.
The question each of them now has to answer is not "is AI dangerous". It is narrower and more awkward: for this particular bug, how confident are we that nobody else has found it, and what is that confidence actually based on?
For a long time the honest answer was "it is hard to find, and few people are looking". For a growing subset of bugs, the first half of that sentence is no longer true, and the second half never offered much protection on its own.
Bitcoin Core is early in saying so out loud. It will not be alone for long, and the projects that take longest to notice will be the ones whose embargo periods are longest — which is to say, the ones with the most to lose from being wrong about it.
One sourcing note: this is reported by crypto outlets describing the policy text rather than from my own reading of the repository, and the figures above come from that coverage. The policy itself is public, and anyone relying on the specifics should read it directly rather than take my summary for it.
Frequently asked questions
What exactly changed in Bitcoin Core's policy?
Triage can now label a vulnerability 'easily discoverable' - findable with minimal effort, such as a simple LLM prompt. Those flaws are patched as quickly as possible across all maintained major releases, with the advisory published at the same time the fix ships rather than weeks afterwards.
Did the other disclosure timelines change?
No. Low-severity flaws are still disclosed two weeks after a fixed major release, and medium and high two weeks after the last affected release reaches end of life. Critical bugs - coin theft, inflation, permanent chain splits - remain outside the standard policy and are handled case by case.
Why does easy rediscovery change the timeline rather than the severity?
Because they are different properties. Severity tells you what happens if a flaw is exploited; discoverability tells you how likely it is that someone else has already found it. Only the second should drive how long you keep it secret, and most triage processes collapse both into a single score.
Is shipping fixes faster straightforwardly better?
No, and it is worth being honest about that. Bitcoin Core's release process is slow on purpose because a bad patch can cause the kind of damage the policy exists to prevent. Faster shipping means less testing. The judgement is that for cheaply rediscoverable bugs this trade is worth making - which is a judgement, not a free improvement.
What about the 4,962 flaws figure?
A review cited alongside the change identified 4,962 potential flaws across 390 Bitcoin-related projects, 85 of them critical. Treat it carefully: automated scanning produces large counts and a potential flaw is not a confirmed one. The direction it indicates is clearer than the number itself.
Does this apply outside Bitcoin?
The reasoning does. Every project with an embargo period is relying on the same assumption - that during the embargo, only the reporters know. That assumption now has to be assessed per bug rather than taken as given, and most disclosure policies have not revisited it.
Sources
Every figure and quote above traces to one of these. Checked on publication day.
- coindesk.com — Bitcoin will now stop hiding bugs an AI can find in one prompt - CoinDesk
- bitcoinmagazine.com — Bitcoin Core Ends Long Embargoes For Bugs AI Can Rediscover - Bitcoin Magazine
- cointelegraph.com — Bitcoin Core Changes Security Policy Amid AI Risks - Cointelegraph
- cryptobriefing.com — Bitcoin Core updates security policy for AI-assisted bug hunting - Crypto Briefing
- tftc.io — Bitcoin Core Changes Disclosure Policy After LLM Threat - TFTC
Deepmoni Das, Editor
I read the primary filings, exchange notices and post-mortems behind each story and write up what they actually say — with every source linked so you can check me. I am not a trader and I do not hold positions in anything covered here. Research and drafting are AI-assisted; the sourcing, the edits and the mistakes are mine.
Not financial advice. Crypto assets are volatile and unregulated in many jurisdictions. In India, gains are taxed at 30% with 1% TDS on transfers. Do your own research and never invest money you cannot afford to lose.
Editorial note: Crypto Shakti uses an AI-assisted research and drafting workflow. Every article is grounded in the linked primary sources and live market data captured at publication time.