Bitcoin Core has added an “easily discoverable” category to its security policy, so bugs that an AI model can find with little effort skip the project’s long embargo periods. Instead they are fixed straight away across every supported release and disclosed alongside the fix, which changes how researchers’ reports are handled and how fast node operators have to upgrade.
What happened
On 22 October 2026, Bitcoin Core developer Antoine Poinsot told the Bitcoin Development Mailing List that the project had changed its vulnerability disclosure policy. The change was made through pull request #1281 on the bitcoincore.org repository. According to Bitcoin.com, Poinsot opened it on 16 October and it was merged on 22 October. The revised policy is now live on the project’s security advisories page.
Poinsot gave a simple reason. The project has received more reports of flaws that are easy to find, or easy to find again, and he puts much of that down to large language models. In his post he said LLMs have sharply lowered the effort needed to uncover certain classes of bug or to spot a fix that was meant to stay quiet. For that kind of flaw he argued the old approach no longer works: “The embargo period achieves little but it delays the availability of a fixed release.”
Crypto Briefing reports that no vulnerability has yet been placed in the new category.
How it works
Bitcoin Core grades reported vulnerabilities as low, medium, high or critical. Until now the policy favoured long secrecy because the project has a slow upgrade culture. Fixes usually stayed out of older branches and reached users only with the next major version. Low-severity issues are disclosed two weeks after a major release that contains the fix. Medium and high-severity issues remain secret until a fortnight after every affected version has been retired, which the policy puts at roughly a year after the fix first shipped. Critical bugs, such as those that could allow coin theft or inflate the supply, are handled case by case outside the standard process.
The new category sits next to these tiers and does not replace them. When a report is triaged, the maintainers can mark it as easy to discover. The policy’s example is a bug that a simple LLM prompt would turn up. Poinsot said the classification is not restricted to LLM-found issues: what counts is how much effort a bug takes to uncover. A flaw marked this way gets a point release for every maintained major version as quickly as possible. A security advisory with some technical detail is published together with those releases. The usual severity-based waiting period does not apply.
The update also clarifies that the two-week pre-announcement, which states how many fixes are coming and at what severity, applies only to vulnerabilities that are still under embargo. Bitcoin.com says other developers in the discussion debated whether users should sometimes be warned before a fix exists. The adopted policy instead calls for advisories to be published alongside the patched releases.
Why it matters for UK organisations
The obvious exposure is among UK businesses that run Bitcoin Core nodes, including exchanges, custodians, payment firms and wallet providers, many of them registered with the FCA. Some of their fixes will now arrive as unscheduled point releases with public advisories on the same day. That narrows the gap between a flaw being explained and someone weaponising it. Firms that upgrade only when a new major version comes out will be exposed for longer under this model, because the details are public as soon as the fix is.
The wider point applies to anyone who runs a vulnerability disclosure programme, whether it is a formal bug bounty, a security.txt contact or the reporting route that UK connectable product makers must already publish under the Product Security and Telecommunications Infrastructure regime. Most of these policies quietly assume that a bug reported in private stays private for a while, so the vendor has time to work. If cheap AI tooling means others can rediscover the same bug within days, that assumption is weaker. Bitcoin Core has now written that into policy. Other open source projects have tried different responses to the flood of AI-assisted reports, and this month’s chaotic PHP release showed how fragile a long embargo can be once details start leaking.
Expert view
I think this is a sensible, honest change. In my experience, embargoes protect users only while the people who know about the bug are a small, trustworthy group. When a well-written prompt against a public codebase can surface the same weakness, the embargo mostly protects the attacker’s head start.
The weak spot is triage judgement. “Easily discoverable” is a call the maintainers make, and the line between easy and hard will move as models improve. That calls for honest re-triage over time. A medium-severity flaw rated hard to find today may not be hard in six months, and the policy text does not yet say how existing embargoed issues will be revisited. Faster point releases also leave less time for testing, a trade-off Poinsot himself acknowledged according to Bitcoin.com. For a consensus-critical codebase, a rushed fix that causes a regression has its own cost.
For researchers, the change is mostly good news. A report marked easy to find should reach users quickly and be credited publicly soon after, instead of disappearing for a year. Silence is the usual frustration for anyone reporting bugs, and a policy that turns some reports into prompt, public fixes addresses it.
What to do now
- Node operators: treat point releases as security updates. Subscribe to Bitcoin Core release and advisory announcements, check the project’s lifecycle page to confirm your version is still maintained, and get off any end-of-life branch, because those will not receive these fixes. This maps directly to the Cyber Essentials security update management control, which expects high and critical fixes within 14 days.
- Shorten your own patch path. Make sure you can test and roll out an unscheduled node release in days, not weeks.
- Review your vulnerability disclosure policy. Ask whether your embargo periods assume a bug cannot easily be found again. Consider a fast-track class of your own for issues that are trivial to reproduce, with a commitment to ship and publish together.
- Update triage criteria. Add “how easily could someone else find this?” to your severity assessment, and re-check open embargoed issues on a schedule as tools improve.
- Tell your researchers. If you change timelines, publish the change in your policy and security.txt so reporters know what to expect and when they will be credited.
Bottom line
Bitcoin Core has accepted that, for a growing class of bugs, secrecy no longer buys much time once AI makes rediscovery cheap. The new category ships fixes everywhere at once and publishes the details with them. That rewards organisations that patch promptly and penalises those that wait for major releases. Every UK organisation that runs a disclosure programme should ask whether its own embargo assumptions still hold.
Sources
- Bitcoin Development Mailing List: Bitcoin Core security policy update (Antoine Poinsot)
- Bitcoin Core: Security advisories and disclosure policy
- GitHub: Update security policy for easy-to-find vulnerabilities (PR #1281)
- Bitcoin.com: Bitcoin Core Changes Security Policy as AI Makes Vulnerabilities Easier to Find
- Crypto Briefing: Bitcoin Core updates security policy for AI-assisted bug hunting
- TFTC: Bitcoin Core Adds ‘Easily Discoverable’ Tier as LLMs Break Embargo Model
