Bitcoin Core new security disclosure Policy

[Ambatman]

I recently came across this and was surprised despite coming up few days ago I couldn't find anything about it on the forum.
As the title stated core have implemented a new policy to combat the growing risk that Ai may pose in finding vulnerabilities.
https://bitcoincore.org/en/security-advisories/



I can understand that such change is needed but wouldn't faster disclosure also expose users who haven't upgraded?
And also on testing time which would likely be reduced or would Ai also be used in the process?

[Donneski]

Maybe they're more concerned in giving users enough time to upgrade before details of a vulnerability become public. You should know that releasing a fix isn't the same as getting users to deploy it, they're two different things. Bitcoin Core can only publish an update, it's then left for node operators to upgrade, some of them do take time to do so. So it might not be ideal to delay disclosure.

While I understand your concern about faster disclosure exposing users who haven't upgraded, it's important for core to find a timeline that gives users a reasonable opportunity to update not just keeping security information hidden longer than necessary and I think that's what they're tryna do.

[DaveF]

Yup if you go to https://coin.dance/nodes and scroll down you can see that there are 1000s and 1000s of people still running Core 25 / 26 / 27 /28
And those are just the reachable ones.
So it's not a bad idea to give people a lot of time.

Now if it's a full RCE error then perhaps a screaming you should update now is not a bad idea. But, for the most part the timeline works for me.

-Dave

[ABCbits]

For anyone who need more context behind policy change, check https://github.com/bitcoin-core/bitcoincore.org/pull/1281.

I can understand that such change is needed but wouldn't faster disclosure also expose users who haven't upgraded?

If it's truly easily discoverable, whoever run old version of Bitcoin Core are exposed either way.

[nc50lc]

I can understand that such change is needed but wouldn't faster disclosure also expose users who haven't upgraded?

Do you mean it'll encourage potential attackers who aren't aware of the vulnerability making the attack more widespread than usual?

If so, those to-be-posted "as soon as possible" are just the ones that are easily discoverable anyways,
So most attackers could re-discover it without the posted security advisory.
It'll bring more benefit for the users to know how to protect themselves against it than the risk of more widespread attacks. (a notification via Bitcoin client would be nice)

More serious security issues wont be disclosed right away as the article mentioned.

[achow101]

I am one of the people involved in handling security disclosures. We spent at least 2 hours probably arguing in person over what the disclosure policy should be when it comes to vulnerabilities reported by people using LLMs to search for vulnerabilities.

This was the policy that we eventually landed on, with the rationale being that any issue that a basic LLM vulnerability scan (e.g. one that almost anyone can do) finds is one that attackers can also find just as easily. Therefore, if there exists a vulnerability that can be easily found, we concluded that t is best to patch it quickly and inform people as soon as possible about the vulnerability to limit the amount of time that attackers have to exploit the vulnerability. This is in contrast to other vulnerabilities (not easily discoverable) where we assume that they are hard to find and therefore hard for attackers to discover them to exploit them.

As an example of this policy in effect, we disclosed 3 easily discoverable vulnerabilities. All 3 vulnerabilities were discovered by Project Loupe which is doing fairly basic LLM scanning. 2 of the vulnerabilities were independently discovered by a contributor who is independently doing LLM scanning. 1 of the vulnerabilities was reported by an individual who is also doing their own LLM scanning. That there were so many duplicate disclosures is indicative that these vulnerabilities were easily discoverable.

[Ambatman]

if there exists a vulnerability that can be easily found, we concluded that t is best to patch it quickly and inform people as soon as possible about the vulnerability to limit the amount of time that attackers have to exploit the vulnerability.

if I'm not mistaken a vulnerability being discovered easily
Doesn't necessarily mean it can be exploited easily
Is there like a classification on this?

Another concern I have is how this policy affects users who purposely chooses not to upgrade to a particular major version
because of features they disagree with or they just love the older known version.

https://bitcoincore.org/en/lifecycle/
So even if they perform backportting there's a likelihood Version 28 won't be worked according to end of life

[achow101]

if I'm not mistaken a vulnerability being discovered easily
Doesn't necessarily mean it can be exploited easily
Is there like a classification on this?

Yes, that is part of the severity classification. Vulnerabilities that have a high impact and are easy to exploit are given higher severity levels. For example, a crash vuln that requires mining a ton of blocks, would likely be assigned a low severity, as even though the impact is high, pulling of an attack would require spending an inordinate amount of compute to do so.

Another concern I have is how this policy affects users who purposely chooses not to upgrade to a particular major version
because of features they disagree with or they just love the older known version.

https://bitcoincore.org/en/lifecycle/
So even if they perform backportting there's a likelihood Version 28 won't be worked according to end of life

We only backport to currently supported releases. This is our longstanding policy, even when we disclose vulnerabilities normally, we do not backport the fixes to EOL versions.

[satscraper]

The latest vulnerabilities ^{disclosed on November 10} are CVE-2025-62859, CVE-2025-62860, and CVE-2026-117349.

That said, your BTC are safe as none of the three found bugs allowed anyone to steal coins, just disruption of effected nodes.

The full list of published vulnerabilities is here.

[DaveF]

We only backport to currently supported releases. This is our longstanding policy, even when we disclose vulnerabilities normally, we do not backport the fixes to EOL versions.

Question on this.
If you found a vulnerability 1 month ago (13-Oct-2026) but not fixed till today (13-Nov-2026) with 32.x coming out in between those dates would it get back ported to the last of the 29.x or just on the newer branch.

Yes, this example is a VERY edge case but just wondering how you do would deal with it.

Because if it's a minor bug that will get fixed but it's on the bottom of the priority list I can see some things sitting out there for a couple of months since exploiting it would be like exploiting CVE-2026-117346. Think of something that is even more minor then that bug but more difficult & costly to exploit.

Yes, asking about an edge hypothetical just picking your brain a bit.

-Dave

[NotATether]

Yup if you go to https://coin.dance/nodes and scroll down you can see that there are 1000s and 1000s of people still running Core 25 / 26 / 27 /28
And those are just the reachable ones.
So it's not a bad idea to give people a lot of time.

Now if it's a full RCE error then perhaps a screaming you should update now is not a bad idea. But, for the most part the timeline works for me.

-Dave

Core needs to give people a way to automatically update it, by downloading the latest version of it and then letting users know by RPC that an update will be applied on restart.

Or even if they just provide a way for Core users to know when a new version of Core has been published so that they can upgrade, that would also be fine.