CVE-2026-104436 in Zebra
Summary
by MITRE • 10/02/2026
Zebra before 4.5.0 contains an uncontrolled resource consumption vulnerability that allows remote P2P peers to exhaust blocking-pool threads by sending oversized block locator vectors. Attackers can send getblocks or getheaders messages with up to 65,535 locator hashes, triggering per-hash chain lookups that degrade block validation, RPC, and mempool performance.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in Zebra versions prior to 4.5.0 represents a critical uncontrolled resource consumption flaw within the peer-to-peer networking layer of the node software. This issue specifically targets the mechanism used for synchronizing blockchain state between nodes through block locator vectors, which are data structures designed to help peers efficiently request missing blocks or headers from their counterparts. In normal operation, these locators allow a requesting node to specify known checkpoints in the chain so that the responding peer can return only the new information required to update its local copy of the ledger. However, the implementation fails to adequately constrain the size or complexity of these vectors when received from remote peers, creating an opening for denial-of-service attacks through resource exhaustion.
The technical root cause lies in how Zebra processes incoming getblocks and getheaders messages that contain excessively large block locator arrays. An attacker can craft a malicious message containing up to 65,535 locator hashes, which is significantly higher than typical operational values. Upon receipt of such a message, the node initiates per-hash chain lookups for each individual hash in the vector. This process involves traversing the blockchain data structures and performing database queries or memory searches to validate the existence and context of each referenced block header. Because this lookup operation is computationally expensive and potentially blocking depending on system load and disk I/O speeds, processing tens of thousands of hashes simultaneously places an unsustainable burden on the node's resources.
The operational impact of this vulnerability extends beyond simple CPU spikes or memory usage increases. The primary consequence is the exhaustion of the blocking-pool threads that handle these intensive lookup operations. As these threads become saturated with malicious requests, they are no longer available to process legitimate network traffic and internal system tasks. This leads to a severe degradation in overall node performance, manifesting as delayed block validation, sluggish response times for Remote Procedure Call (RPC) interfaces used by wallet applications or monitoring tools, and impaired mempool management capabilities where new transactions are queued and validated before inclusion in blocks. In extreme cases, the node may become unresponsive entirely, effectively achieving a denial-of-service condition against both the local operator and potentially other peers that rely on this node for network connectivity.
From a threat modeling perspective, this vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, as well as CWE-770, Allocation of Resources Without Limits or Throttling. The attack vector is classified under MITRE ATT&CK technique T1498, Network Denial of Service, specifically within the context of resource exhaustion via volumetric attacks against application-layer protocols. Since Zebra operates in a trust-minimized environment where peers are not inherently trusted, this flaw highlights the importance of strict input validation and rate limiting at the network protocol level to prevent malicious actors from leveraging standard messaging formats for disruptive purposes.
Mitigation strategies must focus on enforcing strict limits on the size of incoming block locator vectors during message parsing. The software vendor addressed this issue in version 4.5.0 by implementing proper bounds checking and potentially introducing throttling mechanisms that limit the number of concurrent chain lookups initiated per connection or per time interval. Administrators running affected versions should upgrade to Zebra 4.5.0 or later immediately to restore normal operational stability. Until an update is applied, network-level filtering rules can be employed at the firewall or load balancer layer to drop P2P messages that exceed a reasonable threshold for locator hash counts, thereby protecting the node from exploitation while maintaining connectivity with well-behaved peers.