CVE-2026-104429 in Zebra
Summary
by MITRE • 10/02/2026
Zebra (zebrad) 5.0.0 before 6.0.0-rc.0 does not apply its per-peer mempool admission cap to transactions received as direct P2P tx messages, because these are queued without the sending peer recorded as their source. A remote inbound peer can push many unique transactions to occupy a disproportionate share of mempool admission slots, crowding out honest peers' transaction relay.
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 6.0.0-rc.0 represents a critical flaw in the network layer's transaction handling logic, specifically concerning how peer identity is associated with incoming data. In standard Bitcoin-like consensus networks, mempool admission policies are designed to prevent resource exhaustion and ensure fair distribution of block space. A key component of this security model is the per-peer mempool admission cap, which limits the number of unique transactions a single network participant can introduce into the node's memory pool at any given time. This mechanism serves as a primary defense against denial-of-service attacks where malicious actors attempt to flood the network with low-value or spammy data to degrade performance for honest participants. However, in Zebra versions 5.0.0 through pre-6.0.0 release candidates, this enforcement logic contains a significant oversight regarding transactions received via direct peer-to-peer transmission messages.
The technical root cause lies in how the software processes incoming transaction broadcasts. When a node receives new transactions directly from a connected peer, these transactions are queued for validation and potential inclusion in the mempool without correctly recording or associating the sending peer as their source. Because the system fails to attribute these specific transactions to the originating IP address or network identifier, it cannot apply the configured per-peer limits to them. Consequently, any remote inbound peer can bypass the intended restrictions by simply pushing a large volume of unique transactions directly through P2P channels. Since the admission cap is not enforced for this class of data, there is no upper bound on how many items from a single source can occupy mempool slots simultaneously.
This architectural flaw leads to severe operational impacts regarding network stability and fairness. A malicious actor with inbound connectivity can exploit this gap by flooding the node with thousands or even millions of unique transactions. These transactions consume memory pool admission slots that are meant to be shared among all peers, effectively crowding out legitimate transaction relay from honest users. This behavior degrades the responsiveness of the mempool for other participants and can potentially lead to resource exhaustion on nodes with limited memory capacity. The attack vector is particularly dangerous because it allows a single peer to disproportionately influence the state of the node's pending transactions without triggering standard anti-spam defenses, thereby undermining the integrity of the transaction relay network.
From a classification perspective, this vulnerability aligns closely with CWE-787: Out-of-bounds Write in terms of resource consumption logic and more accurately with CWE-400: Uncontrolled Resource Consumption. The failure to enforce access controls on specific input streams constitutes an authorization bypass that leads to denial of service conditions for other network participants. In the context of the MITRE ATT&CK framework, this behavior is indicative of T1498: Network Denial of Service, specifically where the attacker leverages protocol-level weaknesses to exhaust system resources rather than relying on volumetric traffic alone. The exploitation does not require complex payload construction but relies entirely on the volume and uniqueness of transactions sent by a single source that bypasses identity-based throttling mechanisms.
Mitigation for this issue requires an immediate upgrade to Zebra version 6.0.0-rc.0 or later, where the transaction processing pipeline has been corrected to properly associate incoming P2P messages with their originating peers before applying admission caps. Until such updates are applied, network operators should consider restricting inbound connections from untrusted sources and implementing external rate limiting at the firewall or load balancer level to mitigate the risk of mempool flooding. Additionally, monitoring tools should be configured to detect anomalous spikes in unique transaction volume from individual IP addresses, as this serves as a strong indicator that the vulnerability is being actively exploited. Ensuring strict adherence to peer identity tracking during all stages of transaction ingestion is essential for maintaining the resilience and fairness of the consensus network against resource exhaustion attacks.