Bitcoin Core Reveals CVE-2024-52911 Bug That Could Crash Some Bitcoin Nodes
Bitcoin Core discloses bug that could let miners crash nodes
Bitcoin Core has disclosed CVE-2024-52911, a high-severity vulnerability that could let a miner crash some Bitcoin nodes by feeding them a specially crafted invalid block. The fix was already bundled into Bitcoin Core 29.0, but the awkward part is obvious: plenty of node operators still run old versions, and Bitcoin Core does not auto-update. So yes, patched is good. Actually getting people to install the patch is the real sport.
- CVE-2024-52911 affected Bitcoin Core versions after 0.14.0 and before 29.0
- Bitcoin Core 29.0 contains the fix; the vulnerable 28.x line is now end of life
- The attack required enough proof-of-work to mine a block, making it expensive and awkward
- This was a Bitcoin Core software bug, not a failure of Bitcoin’s consensus rules
- No indication has emerged that the flaw was used in the wild
For newcomers: Bitcoin Core is the main software many people use to run a Bitcoin node. A node is a computer that independently checks Bitcoin transactions and blocks instead of trusting someone else’s bookkeeping. That matters because Bitcoin’s strength comes from verification, not blind faith in middlemen or, worse, vibes.
The vulnerability itself was a classic software-security mess: a use-after-free issue in Bitcoin Core’s memory handling. In plain English, the program tried to use data after it had already been freed from memory. That kind of bug can crash software, and in some cases it can open the door to remote code execution, which is the scarier scenario where an attacker might run their own code on the target machine.
Bitcoin Core said the flaw could allow miners to “remotely crash some Bitcoin nodes.” It also noted that while remote code execution was possible, it was considered unlikely. That nuance matters. A crash bug is serious, but a crash bug that might theoretically become code execution is a different level of headache altogether. Still, “unlikely” is not the same as “ignore it and hope.” Cybersecurity has a nasty habit of making fools out of anyone who gets casual.
The exploit was also far from cheap. An attacker would need to mine a specially crafted invalid block with enough proof-of-work to reach the chain tip. Proof-of-work is the computational effort miners spend to produce blocks. In other words, an attacker would need enough real mining power to make the block look legitimate enough for nodes to process it, even though the block would not earn the normal block reward because it was invalid.
That requirement makes the attack expensive and impractical for casual abuse. This was not some clipboard exploit for bored script kiddies with too much energy and a borrowed laptop. The attacker would need serious mining resources, and the economics get ugly fast when the reward is basically “congratulations, you spent money to crash someone’s node.”
The timeline shows the kind of responsible disclosure Bitcoin Core is known for. The bug was privately reported on Nov. 2, 2024 by Cory Fields of the MIT Digital Currency Initiative. Bitcoin Core developer Pieter Wuille then slipped in a covert fix through PR 31112, which was merged on Dec. 3, 2024. The patch later landed in Bitcoin Core 29.0, released in April 2025.
Public disclosure only happened on May 5, 2026, after the last vulnerable 28.x release line reached end of life on April 19, 2026. That delay fits Bitcoin Core’s high-severity disclosure policy: don’t broadcast a bug while users are still supposed to be safely on supported software. Sensible? Yes. A little uncomfortable? Also yes. Decentralized systems are fantastic until you remember human beings are still the ones who have to update the damn software.
That last point is the operational story here. Bitcoin Core does not auto-update. If a node operator forgets, delays, or simply never bothers, the node can sit on vulnerable code for years. That is one of the uglier realities of Bitcoin infrastructure: the protocol can be robust, but the network still depends on people maintaining their machines with something closer to discipline than wishful thinking.
This bug also underlines a distinction that gets blurred too often in crypto headlines. A flaw in Bitcoin Core is not the same thing as a flaw in Bitcoin itself. The consensus rules were not broken here. There was no hidden inflation bug, no magical chain rewrite, no “Bitcoin is compromised” nonsense. The issue was in node software memory handling, which is serious enough on its own without turning it into tabloid-grade panic.
At the same time, it would be lazy to shrug this off just because the exploit path was expensive. High-severity bugs still matter in a system where thousands of independently operated nodes provide redundancy and trust minimization. One bad node crash is a nuisance. A bug that can be weaponized against a subset of operators is a reminder that security is never finished, only maintained. Open-source software is brilliant, but it is not immune to ugly edge cases hiding in plain sight.
For node operators, the takeaway is boring but vital: check your version and upgrade if you are not on Bitcoin Core 29.0 or later. If you’re still on 28.x, you are running an end-of-life release. That’s not a quaint bit of software nostalgia; it’s a liability. And no, “I’ll update later” is not a security strategy. That’s how people end up as cautionary tales in somebody else’s incident report.
- What did CVE-2024-52911 do?
It could let a specially crafted invalid block trigger a memory error and crash some Bitcoin nodes. Bitcoin Core also said remote code execution was possible, though unlikely. - Did it affect Bitcoin’s consensus rules?
No. The bug was in Bitcoin Core’s memory handling, not in Bitcoin’s monetary rules or consensus mechanism. - Could attackers exploit it easily?
No. They would need enough proof-of-work to mine a block, making the attack costly and impractical. - Was the flaw fixed?
Yes. The fix was included in Bitcoin Core 29.0 before public disclosure. - Why was disclosure delayed?
Bitcoin Core waited until the last vulnerable release line reached end of life, following its high-severity disclosure policy. - Why should node operators care?
Because Bitcoin Core does not auto-update, and old versions can remain exposed long after a patch exists.
The bigger lesson is simple: Bitcoin can be resilient without being magical. The network survives because developers find and fix bugs, researchers report them responsibly, and operators actually upgrade their systems instead of treating node software like a wall poster. In Bitcoin, the protocol may be sound, but the machines running it still need adult supervision.