CVE-2026-44499: Permanent Block Discovery Halt in Zebra via Gossip Queue Saturation

CVE-2026-44499 is a composite Denial of Service (DoS) vulnerability affecting the block discovery pipeline of Zebra, a Zcash full node implementation written in Rust. The flaw exists in versions prior to 4.4.0. It leverages three distinct architectural weaknesses in the peer-to-peer (P2P) stack to isolate a target node from the legitimate Zcash network.

The vulnerability allows an unauthenticated remote attacker to completely and permanently halt a node's ability to discover or download new blocks. This results in a high availability impact, as block synchronization is the primary function of a blockchain full node. The issue requires no user interaction and can be triggered via a single persistent TCP connection.

The core of the vulnerability lies in the improper handling of network resource exhaustion and the lack of a robust penalization mechanism for unhelpful network peers. This maps to CWE-770 (Allocation of Resources Without Limits or Throttling) and CWE-400 (Uncontrolled Resource Consumption).

The vulnerability emerges from the convergence of three primary vectors: gossip queue saturation, syncer poisoning, and permanent connection persistence. Zebra's gossip subsystem processes inv (inventory) announcements for new blocks. Prior to version 4.4.0, this subsystem lacked per-connection rate limiting for incoming messages.

An attacker exploiting the lack of rate limits could flood the node with thousands of fabricated block hashes in under a millisecond. This flood immediately pushes the internal gossip download queue to its maximum capacity. Zebra silently ignored the FullQueue error returned by the underlying buffer, discarding legitimate block announcements from honest peers without any recovery mechanism or peer penalization.

Concurrently, the Zebra Syncer component proactively discovers the blockchain via FindBlocks and FindHeaders requests. The Syncer treated empty responses from peers as valid protocol-level events. An attacker responding to these queries with empty inventory lists or NotFound statuses successfully occupied a sync slot indefinitely.

Because the attacker technically adhered to the wire protocol specifications by returning valid but empty responses, Zebra never terminated the connection. The absence of a misbehavior scoring system for these specific interactions ensured the attacker remained permanently connected. This created a perpetual block deficit that the node could not self-heal.

The remediation logic introduced in Zebra 4.4.0 highlights the missing state tracking in earlier versions. The patch implements a FindResponseStallTracker within the PeerSet component. This tracker explicitly classifies connection quality based on response utility rather than mere protocol compliance.

// Patched logic introduced in zebra-network/src/peer_set/set.rs
fn classify_find_response<E>(result: &Result<Response, E>) -> Option<StallOutcome> {
    match result {
        Ok(Response::BlockHashes(hashes)) if hashes.is_empty() => Some(StallOutcome::Stall),
        Ok(Response::BlockHeaders(headers)) if headers.is_empty() => Some(StallOutcome::Stall),
        Err(_) => Some(StallOutcome::Stall),
        _ => Some(StallOutcome::Clear),
    }
}

The function above demonstrates the shift in handling P2P responses. Empty BlockHashes or BlockHeaders responses are now explicitly mapped to a StallOutcome::Stall state. If a peer accumulates three consecutive stalls, the connection is forcefully terminated, preventing the syncer poisoning vector.

In addition to the logic flaw, CVE-2026-44499 was compounded by memory allocation vulnerabilities documented under GHSA-438q-jx8f-cccv. The Equihash solution field and variable-length coinbase scripts relied on CompactSize prefixes provided by network peers. The node allocated memory based on this untrusted prefix before validating the underlying data size against consensus limits.

The deserializer was subsequently hardened. Functions like read_headers now enforce a strict 160-entry protocol limit before parsing. Memory allocation for Equihash solutions and coinbase data is now deferred until the declared size is validated against strict consensus bounds.

Exploitation of CVE-2026-44499 requires a single malicious peer connecting to the target Zebra node over the standard Zcash P2P port. The attack requires no authentication or specific network positioning beyond the ability to establish a TCP connection with the target.

The sequence begins with the attacker initiating a flood of inv announcements to saturate the target's gossip queue. The attacker immediately responds to all subsequent FindBlocks and FindHeaders queries from the target with empty lists.

This behavior satisfies the protocol handshake without delivering any useful blockchain state. The attacker maintains the open TCP connection, continuously serving empty payloads whenever polled. The target node enters a permanently stalled state, incapable of receiving new block information from the attacker or the wider network.

The successful exploitation of this vulnerability results in a total denial of service for the block discovery mechanism. The affected Zebra node becomes permanently isolated from the Zcash network state. It will not append new blocks to its local ledger, meaning any downstream services relying on the node for transaction verification or balance queries will receive stale data.

The CVSS v4.0 score of 8.7 reflects the high availability impact (VA:H). Because block synchronization is the fundamental operational requirement of a full node, halting this process functionally disables the node's primary utility.

The concurrent allocation amplification vectors also pose a significant risk of Out-Of-Memory (OOM) crashes. By supplying manipulated CompactSize prefixes in block headers or coinbase data, an attacker forces the node to attempt multi-gigabyte memory allocations. This combination of logical stalling and resource exhaustion creates a highly effective denial-of-service condition.

The Zcash Foundation addressed these vulnerabilities comprehensively in Zebra version 4.4.0. Upgrading to this version is the only permanent mitigation. The patch introduces fundamental changes to the network protocol handler and deserialization logic.

The most critical architectural change is the implementation of the FindResponseStallTracker. Connections are actively monitored for response quality. Peers that provide three consecutive empty or failed responses to synchronization queries are systematically disconnected. This prevents malicious peers from acting as persistent black holes.

Network resource management was also hardened. The implementation introduces MAX_INBOUND_CONCURRENCY_PER_IP, enforcing a strict limit of one concurrent block download task per IP address. Additional queries from the same source IP are rejected with a TooManyFromPeer status until the initial request completes. Deserialization functions now enforce maximum size limits on arrays and scripts prior to any memory allocation.