Bitcoin Core publicly disclosed CVE-2024-52911 on May 5, 2026 — a high-severity use-after-free vulnerability in the script validation engine that affected all versions from 0.14.0 through 28.x. The bug, discovered by Cory Fields of MIT's Digital Currency Initiative in November 2024, could have al...
"We've been publishing Bitcoin Core security advisories for ~2 years now, and (afaik) we just disclosed the first ever memory safety issue: A use-after-free in the validation engine." — Niklas Gögge, Bitcoin Core Developer
Bitcoin Core publicly disclosed CVE-2024-52911 on May 5, 2026 — a high-severity use-after-free vulnerability in the script validation engine that affected all versions from 0.14.0 through 28.x. The bug, discovered by Cory Fields of MIT's Digital Currency Initiative in November 2024, could have allowed a miner to crash remote nodes and potentially execute arbitrary code by mining a specially crafted invalid block. Pieter Wuille shipped a covert fix in December 2024, disguised as a logging improvement, and the patch shipped publicly in Bitcoin Core v29.0 in April 2025.
Approximately 43% of reachable Bitcoin nodes — an estimated 7,700 to 8,600 out of roughly 18,000-20,000 — are still running pre-v29 software and remain technically exposed. The disclosure arrives at a moment of heightened client fragmentation: Bitcoin Knots has climbed to 19-21% of network nodes amid the OP_RETURN controversy surrounding Core v30, and the v29.1 rollout itself drew 129 negative responses out of 139 community replies. The episode tests a disclosure policy that Bitcoin Core formalized only two years ago and exposes a persistent infrastructure problem — the gap between patching critical software and getting decentralized operators to actually upgrade.
The bug is a use-after-free flaw — a class of memory safety error in which software attempts to access data after that data has already been deallocated. In Bitcoin Core's case, the issue resided in the script validation engine, the component responsible for verifying that transactions in a new block follow Bitcoin's consensus rules.
During block validation, Bitcoin Core pre-calculates transaction input data and dispatches script checks to background threads for parallel processing. Under normal conditions, the cached data persists until all threads complete. CVE-2024-52911 introduced a scenario where a specially crafted invalid block could cause the cached validation data to be destroyed while a background thread was still reading it, creating a race condition.
The consequences fall into two categories:
The vulnerability affected every Bitcoin Core release from version 0.14.0, shipped in March 2017, through version 28.x — approximately seven years of production software.
| Date | Event | |------|-------| | Nov 2, 2024 | Cory Fields (MIT Digital Currency Initiative) privately reports the vulnerability | | Nov 6, 2024 | Pieter Wuille writes a covert fix | | Dec 3, 2024 | Fix merged into Bitcoin Core under PR #31112, titled "Improve parallel script validation error debug logging" | | Apr 2025 | Bitcoin Core v29.0 ships with the fix included | | Apr 19, 2026 | Bitcoin Core v28.x reaches end-of-life | | May 5, 2026 | Full public disclosure of CVE-2024-52911 |
The covert fix is a deliberate element of Bitcoin Core's security response playbook. By disguising the patch as a mundane logging improvement, the development team aimed to prevent attackers from reverse-engineering the vulnerability before node operators had time to upgrade. The 18-month gap between the private report and public disclosure follows the project's policy for high-severity issues: disclosure occurs two weeks after the last affected release line reaches end-of-life.
According to Bitcoin Core developer Niklas Gögge, CVE-2024-52911 represents "the first ever memory safety issue" in approximately two years of the project's public security advisory history. Prior disclosures — including CVE-2024-35202 (remotely triggerable crash), CVE-2024-52914 (node stall denial-of-service), CVE-2024-52921 (block propagation hindrance via mutated blocks), and CVE-2024-52913 (HTLC transaction-relay jamming) — involved logic errors, denial-of-service vectors, or protocol-level flaws. None involved the low-level memory corruption category that CVE-2024-52911 occupies.
According to data referenced by The Block, approximately 43% of Bitcoin's reachable nodes remain on pre-v29 versions. With the network comprising roughly 18,000 to 20,000 reachable nodes (per Bitnodes estimates), this translates to between 7,700 and 8,600 nodes still technically vulnerable.
This upgrade lag is not unusual. Research by Jameson Lopp on Bitcoin node upgrade patterns has documented that Bitcoin operators historically take months to years to adopt new major versions. The decentralized nature of the network — where no central authority can mandate or push updates — means that software adoption follows a long-tail distribution. Some operators run outdated software due to inertia, limited technical resources, or deliberate policy choices.
The 43% figure also needs context. Not all nodes are equal. Mining pool operators, exchanges, and large custodians typically run current versions and monitor security advisories closely. The vulnerable tail likely over-represents individual hobbyist operators and smaller services. However, those nodes still participate in transaction relay and block propagation, meaning their compromise could degrade network performance even if consensus-critical infrastructure remains unaffected.
Exploiting CVE-2024-52911 required mining a block with valid proof-of-work but invalid script data. This means an attacker would need to expend real hashpower — currently measured in exahashes per second on the Bitcoin network — to produce a block that would be rejected by the network and earn zero block reward.
At current difficulty levels, the cost of mining a single block ranges from approximately $150,000 to $300,000 in electricity and hardware depreciation, depending on the miner's efficiency. The attacker would sacrifice this cost with certainty, gaining only the ability to crash nodes running vulnerable software. There is no financial return path: the invalid block cannot be included in the chain, no transaction fees are collected, and no double-spend is enabled by the crash alone.
This cost structure effectively served as an economic deterrent. The vulnerability was exploitable in theory but economically irrational to exploit in practice — at least for profit-motivated actors. State-level or ideologically motivated attackers face a different calculus, but no evidence of such exploitation has surfaced.
Bitcoin Core formalized its security disclosure policy approximately two years ago, establishing tiered timelines based on severity:
A pre-announcement is made two weeks before full disclosure, coinciding with a new major version release. The pre-announcement states the number and severity of forthcoming disclosures without revealing technical details.
CVE-2024-52911 tested this framework at scale. The 18-month covert window gave operators ample time to upgrade — but 43% did not. The policy assumes that the end-of-life expiry of the vulnerable release line creates sufficient urgency. In practice, the data suggests otherwise.
The policy also depends on the covert fix remaining covert. Wuille's PR #31112 passed code review and was merged without public incident. But the strategy carries inherent risk: a sophisticated adversary who monitors Bitcoin Core's commit history could, in theory, identify security-relevant changes despite innocuous titles. The Bitcoin Core team has not disclosed whether any such detection occurred during the 18-month window.
The CVE disclosure lands in the middle of Bitcoin's most significant client fragmentation event in years. Bitcoin Knots, an alternative full-node implementation maintained by Luke Dashjr, has climbed to 19-21.5% of reachable nodes, according to BitRef data. Some estimates place the figure above 25% on certain measurement days.
The migration is driven by the OP_RETURN controversy. Bitcoin Core v30, released in October 2025, raised the OP_RETURN data size limit from 83 to 100,000 bytes. Opponents argue this facilitates "spam" — non-monetary data storage on Bitcoin's blockchain. Bitcoin Knots enforces stricter data size limits and provides operators with tools to filter transactions they consider non-monetary.
The v29.1 rollout itself drew significant backlash. According to reports, 129 out of 139 community replies to the Bitcoin Core Project's announcement were negative, with respondents criticizing the release, promoting Knots, or refusing to upgrade.
For security purposes, client diversity can be a strength: a vulnerability in one implementation does not necessarily affect another. However, CVE-2024-52911 affected the script validation engine, which is shared consensus-critical code. Knots, which is derived from Core's codebase, would have been similarly affected by the underlying bug unless Knots independently applied or inherited the fix. The disclosure advisory addressed Bitcoin Core specifically; Knots' patch status is tracked separately.
The fragmentation raises a secondary concern: as the operator base splits across clients, coordinating security responses becomes more complex. A single disclosure and patch cycle no longer reaches the entire network through one channel.
CVE-2024-52911 is a data point in a longer-running debate about Bitcoin's infrastructure maintenance model. The network secures over $2 trillion in value (at current market prices), yet its reference implementation is maintained by a small group of volunteer and grant-funded developers. The MIT Digital Currency Initiative, which employs the bug's discoverer Cory Fields, is one of a handful of organizations that fund Bitcoin Core security research.
The episode highlights three structural tensions:
Patch velocity vs. decentralization. Centralized software platforms can force-update users. Bitcoin cannot. The 43% upgrade lag is the price of permissionless operation.
Covert fixes vs. transparency. The security community generally favors responsible disclosure, but Bitcoin's open-source ethos creates pressure for transparency. The 18-month covert window is a pragmatic compromise, but it requires trust in a small group of developers to correctly assess severity and manage timelines.
Economic deterrence is not a security guarantee. The high cost of exploiting CVE-2024-52911 likely prevented attacks. But relying on economic irrationality as a defense is fragile. If Bitcoin's hashrate distribution changes, or if a state actor's objectives differ from profit maximization, the calculus shifts.
Bitcoin Core's handling of CVE-2024-52911 demonstrates a maturing security process — structured timelines, covert patching, and coordinated disclosure. The absence of known exploitation validates the economic deterrence model, at least for this class of vulnerability. But the 43% upgrade lag and the growing Core-Knots fragmentation expose limits in the network's ability to respond to future threats that may not carry the same economic barriers to exploitation. The first memory safety bug in Bitcoin Core's advisory history was managed well. The question is whether the infrastructure — social and technical — scales to handle the next one.