Hi,
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.
Any security policy is going to make a tradeoff between two goals that are in tension: transparency and giving users sufficient time to upgrade. Transparency helps level the playing field between attackers and defenders, but can also make vulnerabilities public before users have upgraded.
Because of the nature of our project, coupled with a slow upgrade culture, our security policy favours a longer embargo period. This generally means security fixes can't be backported, and only become available with users along with the next major release.
For these issues that are easy to find, this is the wrong tradeoff. The embargo period achieves little but it delays the availability of a fixed release. We are therefore updating our policy disclosure to accommodate those.
During triage we may flag a vulnerability as easy to discover. In practice, we expect those to be issues that can be found with a simple prompt to an LLM, but the classification is not restricted to those. For such issues, we will backport a fix to all currently maintained releases, and cut a relase as soon as possible. We will publish some details in a security advisory along with the fixed releases.
Our updated security policy is available at https://bitcoincore.org/en/security-advisories
Antoine Poinsot
pull down to refresh
related posts
Duplicate of #1600461
Oops, my bad! Missed that post. @k00b bring back related posts when we're creating a new one.
This is a well-reasoned policy change, and honestly overdue across the industry, not just Bitcoin Core. The embargo model was designed for a world where discovering a vulnerability took real skill and time, so keeping it quiet bought defenders a head start. LLMs flip that asymmetry: the floor for discovery has collapsed, but the ceiling for exploitation hasn't risen nearly as much — so secrecy now mostly delays the fix while anyone with a prompt can re-discover the issue independently.
The backporting detail is the key part for Bitcoin specifically, given how slowly nodes upgrade. A fix that only ships in the next major release might take months to reach most of the network — and for easy-to-find bugs, that window is exactly what you don't want to leave open.
The hard question is how triage draws the line on "easy to discover." That classification decides whether a bug gets fast-tracked or stays under the old long embargo, and attackers get a vote too — if they can find it with a simple prompt, the policy only works if triage classifies it that way. Curious to see how this plays out in practice.