Bitcoin Core discloses a high-severity node-crash bug, CVE-2024-52911, fixed in version 29.0

On 5 May 2026, the Bitcoin Core project published a security advisory for CVE-2024-52911, which it labels a "Script Interpreter Remote Crash" and rates High severity. According to the project's own account (@bitcoincoreorg), the flaw is a use-after-free bug in block validation: a node processing a "specially-crafted block" could end up reading memory that had already been freed, potentially crashing the node.

The affected range, per the project, is "after Bitcoin Core 0.14.0 and before Bitcoin Core 29.0." Bitcoin Core 0.14.0 shipped in early 2017, so the bug sat in released code across most of the software's modern history before being fixed in the 29.0 release. Full details are in the advisory at bitcoincore.org, referenced but not reproduced in the thread we're working from.

How the bug works

The project laid out the mechanics across a short thread. During block validation, Bitcoin Core pre-calculates and caches the data it needs to check each transaction's inputs. That checking is farmed out to background validation threads for speed. The problem: for certain specially crafted invalid blocks, the cached data "could be destroyed while it was still being accessed by a background validation thread." One thread frees the memory; another is still reading it. That's a textbook use-after-free.

The consequences, in the project's words: "An attacker capable of mining a block with sufficient proof-of-work could have exploited this to crash victim nodes." So the immediate, realistic impact is a denial-of-service — a targeted node crash. The project also acknowledged the theoretical worse case: "Because of the nature of use-after-free bugs, it is possible that the crash could have been used for remote code execution, though constraints on the input (block) data make this unlikely." In plain terms: RCE can't be ruled out with a use-after-free, but the project judges it improbable here because an attacker doesn't get free rein over the bytes involved.

The critical qualifier is the entry cost. This is not a bug you trigger with a stray peer-to-peer message. Exploiting it requires mining a block with sufficient proof-of-work — meaning the attacker has to produce a block that clears the network's current difficulty, then get victim nodes to validate it. That is an expensive, hashpower-gated precondition, and it substantially narrows who could realistically pull this off and how cheaply.

Key facts

• CVE-2024-52911, "Script Interpreter Remote Crash," disclosed by the Bitcoin Core project on 5 May 2026. (Source: @bitcoincoreorg thread; advisory at bitcoincore.org/en/2026/05/05/disclose-cve-2024-52911/)
• Rated High severity by the project. (Source: @bitcoincoreorg)
• Use-after-free in block validation: cached per-transaction input data could be freed while a background validation thread was still reading it. (Source: @bitcoincoreorg)
• Affects versions after 0.14.0 and before 29.0; fixed in 29.0. (Source: @bitcoincoreorg)
• Impact: crashes ("kills") victim nodes; RCE described as possible but unlikely given constraints on the block data. (Source: @bitcoincoreorg)
• Exploitation requires mining a block with sufficient proof-of-work — a hashpower- and cost-gated precondition. (Source: @bitcoincoreorg)

The real-world read

A few things are worth stating plainly, because the framing around a disclosure like this can drift fast.

The "2024" in the CVE ID is not a typo — it's the story. CVE identifiers are stamped with the year the number is assigned, not the year of public disclosure. A 2024 ID going public in May 2026 indicates a delayed disclosure of roughly a year or more. That is consistent with Bitcoin Core's standard practice of holding vulnerability details until a fixed release (here, 29.0) is out and node operators have had time to upgrade. It's the responsible pattern, but it also means: if you're still running a pre-29.0 node, this advisory is describing a hole that was live in your software the whole time it was secret. The takeaway is operational — upgrade — not alarmist.

The severity label and the practical bar point in slightly different directions, and both are true. "High severity" is accurate for a remotely triggerable node crash with a non-zero RCE ceiling. But the project's own description also front-loads the mitigant: you need to mine a valid-PoW block to fire it. Burning a block's worth of proof-of-work to crash some nodes is a poor trade for most attackers, which is likely why the advisory could wait for a coordinated fix. Read the "High" and the "you must mine a block" together, not separately.

What's conspicuously not in the material we have. The extracted sources don't include who discovered or reported the bug, a CVSS score, the specific fix commit, or any indication of whether it was ever exploited in the wild. The advisory page itself may cover some of this; we're flagging the gaps rather than filling them with guesses.

Discount the replies. The thread drew the usual crowd. One account joked that Bitcoin Knots "probably has this bug too" — plausible on its face, since Knots derives from Core's codebase and could share the affected validation code, but there is no confirmation of that in these sources, so treat it as unverified. Another reply asserted the bug "was intentional to force wide open OP_RETURN," and others tried to pivot to unrelated grievances about data/"spam" on the chain and wallet handling. None of that is supported by anything in the advisory; it's off-topic and, in the "intentional" case, an unevidenced accusation. We note it only to set it aside.

Sourcing caveat. Everything here traces to a single origin: the Bitcoin Core project's own posts relaying its own advisory. That's an authoritative primary voice on its own software, but it is also an interested party describing its own bug and fix. We've reported its characterizations as its characterizations. The linked bitcoincore.org advisory is the primary document of record; readers who run nodes should consult it directly.

Opinion, and whose

• The Bitcoin Core project characterizes the issue as High severity, assesses remote code execution as "unlikely" due to constraints on the block data, and — by shipping the fix in 29.0 before disclosing — implicitly judges that upgrading resolves it. Those are the project's assessments, not independently verified facts.
• An anonymous reply account (@retardedpleb) speculated that Bitcoin Knots may share the flaw. Unconfirmed.
• Another (@BtcLiberty) claimed the bug was intentional. No evidence supports this; presented here only to identify it as an unfounded claim, not a finding.

The practical read for a node operator is unglamorous: if you run anything from 0.14.0 through the 28.x series, you were exposed, and 29.0 is the fix. That's the whole action item.

Sources

• Bitcoin Core Project (@bitcoincoreorg), thread of 5 May 2026 (via Nitter; Tier 2 relay of the project's own posts) — the disclosure announcement, severity rating, affected version range, the use-after-free mechanism, attacker precondition (mining a PoW block), and the DoS-vs-RCE assessment. Points to the primary advisory at bitcoincore.org/en/2026/05/05/disclose-cve-2024-52911/, which we did not have the full text of.
• Reply accounts in the same thread (@retardedpleb, @BtcLiberty, @Conza) — unverified speculation and off-topic commentary; cited only to identify and discount it. Not sources of fact.

This is reporting on a software security disclosure, not security or investment advice. If you operate a Bitcoin node, verify version details against the official Bitcoin Core advisory before acting.