CVE-2024-35202: Bitcoin Core DOS Vulnerability

CVE-2024-35202 Overview

CVE-2024-35202 is a denial-of-service vulnerability in Bitcoin Core versions before 25.0. Remote attackers can crash a node by sending a blocktxn message containing transactions that are not committed to in a block's merkle root. The flaw triggers an assertion failure in the blocktxn message handler, causing the node process to exit. The root condition is that FillBlock can be invoked twice on the same PartiallyDownloadedBlock instance, violating an internal invariant. The issue is tracked under CWE-770: Allocation of Resources Without Limits or Throttling and is exploitable over the peer-to-peer network without authentication.

Critical Impact

Unauthenticated remote attackers can crash Bitcoin Core nodes running versions earlier than 25.0, degrading availability of the Bitcoin peer-to-peer network.

Affected Products

• Bitcoin Core versions prior to 25.0
• Any full-node deployment relying on the affected PartiallyDownloadedBlock compact-block reconstruction path
• Downstream forks and derivatives that have not merged Bitcoin Core pull request #26898

Discovery Timeline

• 2024-10-08 - Public disclosure by the Bitcoin Core project (Bitcoin Core Crash Disclosure)
• 2024-10-10 - CVE-2024-35202 published to NVD
• 2025-05-22 - Last updated in NVD database

Technical Details for CVE-2024-35202

Vulnerability Analysis

Bitcoin Core implements BIP 152 compact block relay to reduce bandwidth during block propagation. A peer announces a compact block, and the receiving node reconstructs it from short transaction IDs. When transactions cannot be reconstructed from the mempool, the node requests the missing transactions through a getblocktxn message and receives them in a blocktxn response. The receiver assembles the result inside a PartiallyDownloadedBlock object and finalizes it through the FillBlock routine.

The vulnerability arises because FillBlock can be called twice on the same PartiallyDownloadedBlock instance when a peer sends a crafted blocktxn message referencing transactions that do not match the block's merkle commitment. The second invocation violates an internal assertion, terminating the node process. Because blocktxn messages are accepted from any connected peer without authentication, any network participant can trigger the crash.

Root Cause

The defect is a missing state guard in the compact block reconstruction logic. The PartiallyDownloadedBlock object did not enforce a one-shot contract on FillBlock, and the handler did not validate that supplied transactions matched the merkle commitment before reusing the object. The corrective patch in pull request #26898 introduces state tracking that rejects duplicate FillBlock calls and short-circuits the handler when the supplied transactions are inconsistent with the announced block.

Attack Vector

An attacker establishes a standard peer-to-peer connection to a vulnerable Bitcoin Core node. After a compact block is announced, the attacker responds with a blocktxn message containing transactions that are not committed to in the block's merkle root. The malformed message reaches the message handler, FillBlock is invoked a second time on the same object, and the assertion failure shuts the node down. No prior privileges, user interaction, or chain state manipulation are required.

No public proof-of-concept exploit is listed in the enriched data, and the issue is not present in the CISA Known Exploited Vulnerabilities catalog. See the Bitcoin Core Crash Disclosure for the vendor's technical write-up.

Detection Methods for CVE-2024-35202

Indicators of Compromise

• Unexpected bitcoind or bitcoin-qt process exits with assertion-failure messages referencing blocktxn or PartiallyDownloadedBlock in debug.log.
• Repeated reconnections from the same peer immediately preceding node termination.
• Inbound blocktxn messages whose transactions fail merkle root verification logged near the time of crash.

Detection Strategies

• Monitor debug.log for the strings Assertion and FillBlock and alert on matches.
• Track bitcoind process lifecycle through systemd, supervisord, or container orchestration events to detect abnormal exits.
• Correlate node crashes with peer connection telemetry to identify the source of malicious blocktxn messages.

Monitoring Recommendations

• Forward Bitcoin Core logs to a central log store and apply alerting on unplanned shutdowns.
• Capture getpeerinfo snapshots on a schedule so that the peer set at the moment of a crash is preserved for forensic review.
• Track the deployed Bitcoin Core version across all nodes and alert on any host running below 25.0.

How to Mitigate CVE-2024-35202

Immediate Actions Required

• Upgrade every Bitcoin Core node to version 25.0 or later, available from the Bitcoin Core v25.0 release.
• Restart services after upgrade and confirm the version with bitcoin-cli getnetworkinfo.
• Audit peer connections and disconnect untrusted inbound peers until the upgrade completes.

Patch Information

The fix is included in Bitcoin Core 25.0 and is implemented in pull request #26898. Refer to the Bitcoin Core 25.0 release notes for upgrade procedures and the Bitcoin Core Crash Disclosure for advisory context. Operators of downstream forks should rebase onto the patched commit before redeploying.

Workarounds

• Restrict inbound peer-to-peer connections using firewall rules so that only trusted peers can reach the node's 8333/tcp listener until patching is complete.
• Run the node behind a reverse proxy or with -connect= configured to a known set of peers to limit exposure to arbitrary attackers.
• Enable automatic process supervision with rapid restart so that a triggered crash results in minimal downtime while the upgrade is scheduled.

# Configuration example: limit inbound peers to a trusted allowlist
# /etc/bitcoin/bitcoin.conf
listen=1
maxconnections=40
whitelist=10.0.0.0/8
bind=127.0.0.1
# Restart the service after applying changes
sudo systemctl restart bitcoind
bitcoin-cli getnetworkinfo | grep subversion