Bitcoin Core Rewrites Security Policy as LLMs Make Some Bugs Easy to Rediscover

Introduction

Bitcoin Core’s developers have updated the project’s security policy to address a new reality: large language models (LLMs) can surface certain bugs with minimal effort. The revised rules create an “easily discoverable” vulnerability class that triggers rapid fixes and immediate public advisories, bypassing the longer embargo periods traditionally applied to most security issues.

Why the Policy Needed a Refresh

The change stems from a noticeable uptick in reports of flaws that can be reproduced by feeding a straightforward prompt to an LLM. Contributors observed that these bugs, while not always critical, become public knowledge quickly once an AI model is queried. The previous embargo—often up to a year for medium and high‑severity bugs—meant that users would continue running vulnerable code while the fix languished in development branches. By the time the patch was back‑ported to older releases, the vulnerability had already been demonstrated in the wild.

Defining the “Easily Discoverable” Category

Under the new policy, a vulnerability qualifies as “easily discoverable” when:

1. It can be reproduced with a simple LLM prompt or comparable low‑effort technique.
2. The issue does not require deep protocol knowledge or extensive manual analysis to locate.
3. The fix can be applied to all maintained major versions without extensive re‑testing.

When a bug meets these criteria, the core team will:

• Issue a point release containing the fix as soon as possible.
• Publish a security advisory alongside the release, foregoing the standard severity‑based embargo.

Bugs that fall outside this class continue to follow the existing timeline: low‑severity bugs are disclosed two weeks after a major release, medium and high‑severity bugs remain private until the affected release is out of support for roughly a year, and critical bugs are handled on a case‑by‑case basis.

Community Debate and Implementation

The proposal, opened by contributor Antoine Poinsot, sparked discussion among developers. Some argued that rapid disclosure could aid attackers who monitor the repository, while others noted that the very act of fixing the bug would expose it anyway. A compromise emerged: public advisories would accompany the fix, providing users with actionable information without revealing exploit details that could be weaponized. The pull request was merged by Michael "fanquake" Ford after gaining consensus from several core contributors. The new classification is intentionally broader than AI‑only findings; any flaw that can be uncovered with minimal effort—whether via an LLM, a simple script, or a basic static analysis tool—fits the definition.

Practical Implications for Users and Developers

For node operators and wallet developers, the policy shift means faster access to patches for a subset of vulnerabilities that were previously delayed by embargoes. While the rapid release cadence may reduce the amount of testing time before deployment, the trade‑off favors security in an environment where AI can democratize bug discovery. Developers working on downstream projects should monitor Bitcoin Core’s advisory feed closely. When an “easily discoverable” advisory is published, they can prioritize integrating the corresponding point release into their own release pipelines, minimizing exposure windows.

Closing Thoughts

Bitcoin Core’s policy rewrite acknowledges that AI tools are reshaping the threat landscape. By creating a dedicated pathway for low‑effort, high‑visibility bugs, the project aims to keep the network’s security posture ahead of the curve. The approach balances the need for swift remediation with responsible disclosure, offering a pragmatic template for other open‑source projects confronting similar AI‑driven challenges.