Bitcoin bug allowed miners to run code on other people’s nodes

Bitcoin Core developers today disclosed a bug that has allowed miners to remotely crash and execute code on other people’s nodes.

The vulnerability, CVE-2024-52911, has affected Bitcoin Core 0.14.1 through 28.4. Developer Cory Fields responsibly disclosed and helped patch the high severity error via Pull Request (PR) 31112.

Had a miner wanted to utilize the dark trick, they could have executed software code on assorted nodes across the globe.

Fortunately, the bug remained obscure and likely not utilized due to its incredibly expensive attack vector.

Specifically, the attack required a miner to direct electricity-guzzling hashpower toward mining special types of blocks. A guaranteed opportunity cost, these invalid blocks could not become eligible for an actual coinbase reward to recoup the miners’ electricity costs.

Still, the mechanism of attack is easy to understand, albeit expensive to conduct.

A miner that produced a specially crafted block with sufficient proof-of-work could either crash victim nodes and/or use the crash to overtake its memory for remote code execution.

Bitcoin Core admitted that remote code execution was possible, although it did not cite specific examples of it occurring. It highlighted not only its cost and old age, but also the constraints on block data that have made it historically unlikely that miners engaged in meaningful episodes of puppeteering.

Old Bitcoin nodes still at risk of bug

Bitcoin Core’s advisory describes the bug as a script interpreter crash. During block validation, Bitcoin Core software pre-calculates and caches transaction input data, then dispatches script validation work to background threads that use computer memory.

If subjected to a CVE-2024-52911 attack, the node could keep reading from its cached memory after that data had already been freed from memory by another process.

Because this attack is a use-after-free memory bug, remote code execution is possible during this abnormal memory state.

In particular, remote code execution could occur when the node’s background script thread read cached, precomputed transaction data after it had been destroyed by a script validation, CScriptCheck.

Because upgrading a Bitcoin full node is voluntary and software updates are not automatic, a not insignificant minority of the network has delayed upgrading to version 29 (v29) or above.

Specifically, according to one popular estimate, as much as 43% of Bitcoin nodes are still running vulnerable full node software based on pre-v29 code.

Responsible disclosure in 2024

As early as November 2024, Cory Fields detected and privately reported the bug.

Four days after detection, Pieter Wuille pushed a fix proposal as PR 31112, titled “Improve parallel script validation error debug logging.”

The advisory purposefully read like a mundane, maintenance-style plumbing fix. Raising no alarm bells, it fixed Bitcoin Core’s check queue return handling and script validations.

Quickly, the PR by Fields and Wuille gained technical consensus for a merge into production by December 2024. Bitcoin Core 29.0 shipped with the fix by April 2025, and the final vulnerable release line, versions 28.x, reached end-of-life on April 19, 2026.

Now that node operators have had many months to upgrade, and in keeping with a policy in recent years of publicly disclosing old, previously secret bug fixes, Bitcoin Core finally announced the bug today on its website.

Bitcoin Core developer Niklas Gögge correctly noted that this is “the first ever memory safety issue” bug in Bitcoin Core. He thanked Fields for his responsible disclosure.

Bitcoin’s consensus rules were not changed by the bug fix. The bug was in node software and its use of computer memory checks, and the fix is already in current Bitcoin Core releases v29 and later.