CVE-2024-52911: Bitcoin Core Miners Could Have Crashed Nodes, Executed Remote Code

Bitcoin Core developers just went public with a nasty bug. CVE-2024-52911. Miners could’ve crashed nodes and run code on them remotely. The flaw sat in versions 0.14.1 through 28.4, and developer Cory Fields found it last November. Pull Request 31112 fixed it.

The attack wasn’t cheap, though. A miner wanting to exploit this would need to throw serious hashpower at mining special blocks. And those blocks? They wouldn’t earn a coinbase reward. That made the whole thing pretty expensive and unattractive. No one reported seeing this happen in the wild, probably because burning money to crash nodes didn’t make much sense. Fields figured out the bug was a use-after-free memory problem buried in Bitcoin Core’s validation engine. Craft the right kind of block, and you could crash victim nodes. Maybe even execute code on them.

How the Memory Bug Worked

Bitcoin Core called it a script interpreter crash. Here’s what happened during block validation: the software cached transaction data, then sent it off to background threads. If someone pulled off the attack, nodes would read memory that had already been freed. That’s when things got dangerous. Code execution became possible.

The fix landed in version 29 and later releases. But upgrading? That’s voluntary. And a lot of nodes haven’t bothered. Estimates put the number at around 43% still running pre-v29 software. Bitcoin Core’s advisory makes it clear: outdated nodes are sitting ducks.

Fields reported the bug in November 2024. Four days later, Pieter Wuille proposed a fix. The patch got consensus fast and made it into Bitcoin Core 29.0 by April 2025. Today the team disclosed everything publicly, following their usual policy of transparency around old vulnerabilities.

The bug didn’t mess with Bitcoin’s consensus rules. It was all about how node software handled memory. Fields did the responsible thing by disclosing it privately first, and the patching process went smooth.

Network Still Exposed

The use-after-free memory bug lived in the validation engine. When cached transaction data got read after being freed, things went sideways. That abnormal state opened the door to remote code execution. Anyone running outdated software faced real risk. The fix in Bitcoin Core 29.0 tackled these memory safety issues head-on, shutting down the exploit path for future versions.

Bitcoin Core’s disclosure strategy aimed for stability without freaking everyone out. The advisory looked like routine maintenance—just improving script validation error logging, nothing to see here. That let the development team roll out the fix quietly and get wide adoption without causing panic in the community.

But here’s the problem: a big chunk of the network still runs old software. That’s the headache with decentralized systems. Upgrades are voluntary, so many operators haven’t moved to the safer versions yet. The vulnerability is still out there, waiting.

The attack scenario was unlikely, sure. High cost, complicated setup. But the potential for remote code execution was real, and that posed serious risk to the network. The Bitcoin Core team has worked to make sure future releases don’t have similar holes.

Disclosure came after thorough review and consensus inside the development community. It took a collaborative effort to keep Bitcoin’s infrastructure intact. Developers like Fields and Wuille jumped on the issue fast, showing how proactive the Bitcoin Core team can be when it matters.

Despite the patch being out there, the voluntary upgrade process means part of the network still operates on vulnerable versions. That’s the ongoing challenge with decentralized networks—getting everyone to update. And it prevents potential exploits only if people actually do it. Bitcoin Core keeps working on security measures, and node operators need to upgrade to the latest versions to stay protected.

Quiet Fix, Public Disclosure

The vulnerability stayed under wraps initially to prevent exploitation while developers worked on a fix. That kept the network secure during the patching process. The fix eventually shipped in Bitcoin Core 29.0, which included better handling of script validation errors and improved memory management practices.

Going public with the bug is part of Bitcoin Core’s broader transparency effort. By revealing the vulnerability and the steps taken to fix it, developers want to reinforce how important it is to keep software current. And they want to show the ongoing commitment to security.

A significant number of nodes haven’t upgraded yet. That’s a common challenge in decentralized systems where updates aren’t mandatory. The presence of outdated nodes means there’s still a need for awareness and action among node operators to reduce risks tied to vulnerabilities like this one.

Fields’ discovery came at a critical time. The bug had existed across multiple versions, affecting a wide swath of the network. The quick turnaround from discovery to patch showed how responsive the development community can be when security is on the line.

The cost factor probably saved the network from seeing this exploited. Mining blocks that don’t pay out? That’s a tough sell for anyone, even attackers. But the theoretical risk was there, and that’s what mattered to the developers who worked on the fix.

Node operators who haven’t upgraded are basically rolling the dice. The patch is available. The vulnerability is known. And 43% of the network is still exposed. That’s a lot of nodes sitting on old code, vulnerable to an attack that could crash them or worse.

The disclosure today marks the end of the quiet period. Bitcoin Core waited until the patch had time to spread before going public. That’s standard practice for responsible disclosure, giving people time to update before attackers know what to look for.

Wuille’s fix addressed the core memory issue, preventing the use-after-free condition that made the exploit possible. The changes in version 29.0 weren’t flashy, but they closed a door that shouldn’t have been open in the first place.