Zebrad <= 4.4.1 - CraftedSignal Threat Feed

Zebra Block Suppression Vulnerability (CVE-2026-52736) via P2P Body Poisoning

hello@craftedsignal.io — Fri, 03 Jul 2026 11:34:34 +0000

A high-severity vulnerability, CVE-2026-52736, affects Zebra's zebrad blockchain nodes, specifically versions up to v4.4.1, as well as zebra-state up to v6.0.0. This flaw allows a remote, unauthenticated attacker to conduct a denial-of-service attack against a target node by exploiting a caching issue in how zebrad handles block hashes. By leveraging coinbase scriptSig malleability (ZIP-244 txid_v5) to create a poisoned block body with the same header hash as a legitimate canonical block, an attacker can cause the node to cache the hash and then reject the actual valid block as a duplicate. This leads to the node permanently stalling at a specific block height, diverging from the network tip, and preventing downstream services like lightwalletd, wallets, and explorers from advancing. The attack requires winning a propagation race to deliver the poisoned block before honest peers deliver the canonical one, which a well-positioned attacker can reliably achieve.

Attack Chain

Attacker observes a new block header from any peer on the network.
Attacker constructs a poisoned block body that has an identical header hash to the observed block, achieved by mutating the coinbase scriptSig extra-data section.
Attacker advertises the hash of this specially crafted block to the target Zebra node via an inv (inventory) message over the P2P network.
The target Zebra node requests the advertised block via a getdata message, and the attacker serves the poisoned body.
Zebra adds the block hash to its non_finalized_block_write_sent_hashes cache before completing contextual validation of the block body.
The write task within Zebra subsequently rejects the poisoned body due to an auth_data_root mismatch (specifically, block_commitment_is_valid_for_chain_history fails), but the hash is not removed from the non_finalized_block_write_sent_hashes cache.
When the valid, canonical block later arrives from honest peers or an RPC connection, Zebra's queue_and_commit_to_non_finalized_state function sees the hash already in the cache and erroneously treats it as a duplicate, returning KnownBlock::WriteChannel.
The target Zebra node fails to advance past the affected block height (N-1), becoming permanently stalled until a manual restart (which clears the in-memory cache) or a rare chain reorg event occurs.

Impact

Successful exploitation of CVE-2026-52736 leads to a permanent denial of service for the targeted Zebra node, causing it to diverge from the main blockchain network. This renders the node unable to process new blocks, effectively stalling its operation. Downstream services and applications that rely on the affected node, such as lightwallets, block explorers, and potentially mining infrastructure, will experience service degradation or complete outages due to an inability to access up-to-date blockchain data. Recovery from this attack typically requires manual intervention, specifically restarting the zebrad process to clear the in-memory sent-hash cache, or waiting for an unlikely chain reorg at the stalled height. There is no information on specific victim counts or sectors, but any organization operating vulnerable Zebra nodes is at risk.

Recommendation

Immediately patch all zebrad nodes to version v4.4.2 or later to remediate CVE-2026-52736, which includes a fix for removing stale entries from the sent-hash cache.
While not a complete solution for CVE-2026-52736, consider reducing the network.peerset_initial_target_size configuration to narrow the attack surface by limiting the number of inbound P2P connections.
Be prepared to restart zebrad nodes if they stall at a specific block height, as this is the primary recovery mechanism to clear the in-memory non_finalized_block_write_sent_hashes cache.

Zebra Node Denial-of-Service via IPv4-Mapped Mempool Misbehavior Panic (CVE-2026-52829)

hello@craftedsignal.io — Fri, 03 Jul 2026 11:25:58 +0000

A high-severity vulnerability, CVE-2026-52829, affects Zebra zebrad nodes up to version 4.4.1 and zebra-network up to 6.0.0, potentially allowing a remote denial-of-service. An address normalization mismatch occurs when a peer connects via IPv4 to a dual-stack IPv6 listener (the default [::] address on Linux with net.ipv6.bindv6only=0), and subsequently triggers a mempool misbehavior penalty by advertising an invalid transaction. The zebrad software stores the peer's address in a canonical IPv4 form during the initial handshake, but later attempts to update its misbehavior status using the raw IPv4-mapped IPv6 address from the transient socket. This inconsistency leads to a deterministic assertion panic after a 30-second delay, terminating the zebrad process. This issue is critical for any zebrad node synchronized near the chain tip in a production environment as it enables persistent downtime.

Attack Chain

An unauthenticated attacker initiates an IPv4 connection to a vulnerable zebrad node listening on a dual-stack IPv6 address (e.g., [::] on Linux with net.ipv6.bindv6only=0).
During the P2P handshake, the zebrad node's address book canonicalizes the IPv4-mapped IPv6 address (e.g., ::ffff:127.0.0.1) to a plain IPv4 address (e.g., 127.0.0.1) and stores it.
The attacker advertises an invalid mempool transaction, such as a coinbase transaction, which the zebrad node attempts to download.
The zebrad node identifies the transaction as invalid and queues a misbehavior penalty for the peer, forwarding the raw IPv4-mapped IPv6 transient socket address.
After a 30-second batch flush, the address book attempts to apply the misbehavior update to the stored peer entry.
An internal assertion (previous.addr == self.addr()) fails because the canonical IPv4 address originally stored does not match the raw IPv4-mapped IPv6 address received for the misbehavior update.
This mismatch triggers a panic = "abort", causing the zebrad process to terminate, resulting in a denial-of-service.
The attacker can repeat this sequence after each node restart, leading to persistent downtime.

Impact

This vulnerability allows any remote, unauthenticated peer to deterministically crash a synced Zebra node running in its default Linux dual-stack configuration. The attack requires no mining capability, RPC access, funds, or special privileges, making it highly accessible to adversaries. The zebrad process terminates abruptly, leading to service disruption. Since the attack can be repeated reliably after each restart, it poses a significant threat of persistent denial of service, impacting the availability and stability of the Zebra network. Nodes operating as part of critical infrastructure, such as those maintaining blockchain consensus, would face severe operational issues.

Recommendation

Patch CVE-2026-52829 by upgrading zebrad to version 4.5.0 or higher immediately.
As a temporary workaround, configure zebrad's listen_addr to bind only to an IPv4-only address (e.g., 0.0.0.0:8233) to prevent the use of IPv4-mapped IPv6 representations.
Alternatively, on Linux hosts, set the kernel parameter net.ipv6.bindv6only=1 to disable dual-stack acceptance on IPv6 listeners, thus preventing the vulnerable condition described in CVE-2026-52829.