What happened
On 3 July 2024, Antoine Poinsot posted a security disclosure policy to the Bitcoin development mailing list on behalf of six contributors. Hours later the project published ten advisories at once, covering vulnerabilities fixed in versions up to and including 0.21.0.
The policy sorts reports into four classes. Low is "bugs which are hard to exploit or have a low impact", Medium is "bugs with limited impact", High is "bugs with significant impact", and Critical is "bugs which threaten the whole network's integrity. For instance an inflation or coin theft bug."
The timing follows from the class. Low severity bugs are disclosed two weeks after a fixed version is released. Medium and high severity bugs wait until two weeks after the last affected release reaches end of life, about a year after the fix shipped. Critical bugs sit outside the schedule entirely, because they "would most likely require an ad-hoc procedure."
The backlog is being worked through in order: bugs fixed in 22.0 later in July, 23.0 in August, "and so on until we run out of EOL versions".
What it changes
It changes what a node operator knows when deciding whether to upgrade, and that is the whole point.
Bitcoin has no update mechanism, deliberately. Nobody can push a patch to anyone's machine, and a node running a four year old version will keep validating blocks indefinitely. Staying on an old release is therefore a risk decision that somebody is making, and until now they were making it with no information.
The announcement is unusually blunt about why this needed fixing. The project "has historically done a poor job at publicly disclosing security-critical bugs, whether externally reported or found by contributors", and the result is that many users came to believe Bitcoin Core simply does not have bugs. That impression, it says, is "dangerous and, unfortunately, not accurate."
The archive that opened the same day makes the gap concrete. One of the ten, a flaw letting a crafted unconfirmed transaction stall a node for hours, was reported in March 2019 and fixed in 0.18.0 two months later. It was disclosed five years after the fix shipped.
What it does not change
It does not make old versions safe, and it does not make anyone upgrade. It publishes the information and leaves the decision where it already was.
It says nothing about bugs not yet found. The schedule governs vulnerabilities already known and fixed, so a current release with no published advisories is not a release without defects.
The hardest case is explicitly excluded. A critical bug, the inflation or theft category, gets no timeline at all, because coordinating a fix for one without telling an attacker first is a problem no policy can solve in advance.
Context
The old practice was to fix quietly and ship. It was not always possible: the inflation bug in 0.16.3, in September 2018, was severe enough that it had to be explained at the time. But quieter ones went out with no announcement, and some were held for years by deliberate decision rather than oversight.
This is ordinary practice elsewhere. Most maintained software publishes advisories on a schedule, under some form of coordinated disclosure. What makes it awkward here is that the software validates money for people who cannot be contacted, on machines that may never be updated, and disclosure reaches them and an attacker in the same moment. The policy's answer is to wait until the affected releases are past end of life, then say everything.