Why Node Operators Need to Act Now
A high-severity vulnerability in Bitcoin Core — silently patched in December 2024 and shipped with v29.0 in April 2025 — was publicly disclosed on May 5, 2026. The delay was intentional: Bitcoin Core follows a responsible disclosure policy that withholds details until affected software versions reach end-of-life. That threshold was crossed on April 19, 2026, when the 28.x line was retired.
The problem: roughly 43% of active Bitcoin nodes are still running pre-v29.0 software and remain exposed to a bug that, under specific conditions, could allow a miner to crash them remotely.
What the Bug Actually Does
CVE-2024-52911 is a use-after-free vulnerability. In plain terms: the software continued reading from a block of memory after that memory had already been freed.
The specific mechanism involves how Bitcoin Core handles transaction script validation. The software pre-calculates input data and dispatches script checks to background threads. For a specially crafted invalid block, it was possible for the cached data to be destroyed while a background thread was still reading it — triggering a crash.
Bitcoin Core confirmed that an attacker with sufficient proof-of-work could have exploited this to crash victim nodes. The advisory notes it is "possible" — though "unlikely" given input constraints — that the crash could be weaponised for remote code execution.
The Responsible Disclosure Timeline
The discovery was made by Cory Fields of the MIT Digital Currency Initiative, who privately reported the bug on November 2, 2024. Four days later, Pieter Wuille — one of Bitcoin's most prolific protocol contributors — submitted a covert fix via pull request #31112. The fix was merged on December 3, 2024, and shipped publicly as part of Bitcoin Core v29.0 in April 2025.
Public disclosure waited until the 28.x version line officially reached end-of-life on April 19, 2026. This is the standard practice: announce only after the window for silent upgrades has closed and the vulnerable software is no longer supported.
Why the Attack Was Never Used
The economic structure of the Bitcoin network made exploitation self-defeating. Any miner attempting to weaponise this bug would have needed to mine an invalid block — consuming real hashpower and electricity — with zero block reward. There is no known instance of exploitation in the wild.
That said, 'never used' is not the same as 'not worth fixing.' The vulnerability existed for over 14 months before public disclosure. Any miner or mining pool that discovered it independently during that window could have used it to degrade network resilience by crashing a significant fraction of nodes. A network with fewer healthy nodes is a less censorship-resistant network.
The Upgrade Gap Problem
What makes this story uncomfortable is not the vulnerability itself — responsible disclosure, a swift covert fix, and a low-exploitation-likelihood profile are about as good as it gets for security response. The problem is the 43% figure.
Nearly half of all reachable Bitcoin nodes are running software that was patched over a year ago. This is not a new problem. After every major Bitcoin Core release, a substantial tail of unupgraded nodes persists for months or years. The reasons vary: hobbyists who set up a node and forgot, home miners running embedded software, institutions with slow change-management processes.
The implication is structural: security patches in Bitcoin Core depend on voluntary adoption. There is no auto-update mechanism. There is no kill switch. Upgrading is the node operator's responsibility.
What To Do
If you run a Bitcoin node, check your version. If it is below 29.0, upgrade to the current release immediately. The Bitcoin Core releases page has the latest stable build.
If you are unsure how to check: run bitcoin-cli getnetworkinfo and look for "version". Anything below 290000 is vulnerable.
Bitcoin Gate Take
This is exactly the kind of story that gets ignored in bull markets and blamed on "the devs" when something goes wrong. The Bitcoin Core team handled the disclosure correctly — fast covert patch, responsible timeline, clear advisory. The failure mode is not the developers. It is the 43% of node operators who have not upgraded in over a year. If you run a node, you are part of Bitcoin's security infrastructure. Act like it.