Bitcoin Core has changed how it handles security vulnerabilities that can be discovered with little effort. A policy update merged on October 22 responds to developers’ concern that language models have made some flaws and previously discreet fixes easier to identify.
TL;DR: Easily discoverable vulnerabilities can now trigger prompt fixes across maintained versions and accompanying advisories. Other reports continue to follow the project’s severity-based disclosure timetable.
The balance between secrecy and patch availability shifts
In the proposal, developer Antoine Poinsot described an increase in reports of flaws that could readily be found again. He argued that a long embargo provides limited protection when an attacker can independently identify the issue, while delaying the availability of a fixed release.
The adopted security policy now separates those cases during triage. For an issue classified as easily discoverable, maintainers aim to issue a patch for each maintained major version as soon as possible and publish an advisory alongside it, without the ordinary embargo.
The definition includes issues found through a simple LLM prompt, but is not restricted to a particular tool. The relevant question is how readily the vulnerability can be discovered, not whether the original reporter used artificial intelligence.
That distinction avoids treating every machine-generated report as equally urgent or equally credible. A report still needs assessment, a fix still needs review, and the potential effects on users remain separate from how the initial lead was produced.
Severity and supported versions still matter
For other vulnerabilities, the policy retains different timelines. Low-severity issues are generally disclosed two weeks after a major release containing the fix. Medium- and high-severity issues wait until two weeks after the last affected release reaches the end of support. Critical cases are handled individually.
The project’s separate security instructions direct researchers to its dedicated reporting address and supported-version schedule. That matters because a promise to backport fixes to maintained releases does not extend maintenance indefinitely to every version ever distributed.
For operators, the change makes the relationship between an advisory and an available update more direct in the easily discovered category. It also increases the importance of knowing which software version is actually running across a service’s nodes, rather than relying on a general statement that the infrastructure uses Bitcoin Core.
The policy does not identify a newly exploited flaw or claim that the Bitcoin network has suffered a corresponding loss. It changes the procedure for handling qualifying reports, including how quickly corrected software should become available.
The underlying trade-off remains difficult. Disclosing an issue can help defenders understand why an upgrade matters while also telling attackers where to look. The new rule acknowledges that withholding details offers less protection when discovery is already inexpensive, and gives greater weight to getting a reviewed fix into operators’ hands.
Written by the News Desk and edited by Samuel Rae.