Description

Zebra before 6.1.0 contains an inefficient algorithmic complexity vulnerability in remaining_transaction_value that clones the entire block-level spent-UTXO map per transaction during contextual verification. Attackers can mine or seed the mempool with roughly 26,000 minimal single-input transactions in one block, stalling every validating node for over 52 seconds.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-10-02T12:17:12.887Z",
  "pubdate": "2026-10-02T12:17:12.887Z",
  "executiveSummary": "Zebra versions prior to 6.1.0 are susceptible to an algorithmic complexity vulnerability located within the contextual verification logic. The vulnerability manifests as an inefficient resource utilization flaw during the processing of the remaining_transaction_value function. Specifically, the node implementation clones the entire block-level spent-UTXO map for every single transaction encountered during block validation.\nThis behavior introduces a severe denial-of-service vector where an attacker can craft or inject specific transaction sets into the mempool. By populating a block with approximately 26,000 minimal single-input transactions, an attacker can induce a processing stall exceeding 52 seconds per node. This effectively cripples the network's ability to validate blocks in real-time, leading to potential chain synchronization failures or widespread node exhaustion. The vulnerability does not require authentication or elevated privileges, as the attack is feasible through standard transaction submission channels. The risk to the ecosystem is critical, as it allows for trivial resource exhaustion attacks that disrupt consensus operations.",
  "technicalDetails": "The root cause of the vulnerability resides in the architectural design of the contextual verification process within Zebra versions prior to 6.1.0. During the validation of individual transactions, the function remaining_transaction_value performs an expensive data structure operation: it clones the entire spent-UTXO map maintained at the block level. Under normal conditions, the performance impact of this operation may be acceptable; however, the complexity scales poorly when processing blocks containing a large number of minimal transactions.\nThe exploitation flow begins with the attacker crafting a block containing approximately 26,000 transactions. Each transaction is designed to be minimal—containing only a single input—thereby maximizing the transaction count per block while minimizing the data per transaction. As the node begins contextual verification for these transactions, it invokes the vulnerable remaining_transaction_value function for each entry. Because the implementation creates a deep copy of the block-level spent-UTXO map for every single transaction, the memory allocation and CPU cycles required scale linearly with the number of transactions, effectively reaching O(N * M) complexity, where N is the number of transactions and M is the size of the UTXO map.\nThis amplification results in a processing latency of over 52 seconds for a single block of the specified size. Given the temporal constraints of block propagation and consensus requirements, such a delay is sufficient to force nodes to lag significantly behind the chain tip, effectively inducing a denial-of-service state. The vulnerable component is specifically the state-handling logic within the contextual verification suite of the Zebra software. The exploitation is network-exposed, as any actor capable of submitting transactions to the mempool or mining a block can trigger the computation. No special authentication is required, as the validation of these transactions is a standard component of node operation. The post-exploitation impact is a total collapse of consensus participation for affected nodes, rendering them unable to process incoming blocks within the network's block time constraints, potentially leading to a partitioned network state."
}