CVE-2026-104424 in Zebra
Summary
by MITRE • 10/02/2026
Zebra before 6.1.0 contains an incorrect calculation vulnerability in its ZIP-317 block template selector that omits header and transaction-count size from the block budget. Attackers can place valid selectable transactions in a victim miner's mempool to shape templates into oversized blocks, causing rejection and wasted proof-of-work.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in Zebra versions prior to 6.1.0 represents a critical logic error within the consensus-critical block template selection mechanism, specifically affecting the implementation of ZIP-317 for Zcash miners. This flaw stems from an incorrect calculation of the maximum allowable size for mined blocks, which fails to account for the fixed overhead required by the blockchain protocol structure. In standard proof-of-work mining protocols, a valid block consists not only of transaction data but also includes essential header information and metadata such as the count of transactions included in that specific block. The Zebra node software, when acting as a miner or providing templates to miners, incorrectly calculated the remaining budget for transactions by neglecting to subtract these fixed-size components from the total block size limit defined by the network consensus rules.
This miscalculation creates a significant operational risk where the generated block template exceeds the maximum allowed size permitted by the Zcash protocol specifications. When a miner attempts to submit this oversized block to the network, it is immediately rejected as invalid because it violates the fundamental structural constraints of the blockchain. This rejection results in a complete waste of computational resources and energy expended during the proof-of-work process without any reward for the mining effort. For individual miners operating on affected versions of Zebra, this leads directly to financial loss due to wasted electricity and hardware wear, while also reducing their effective hashrate contribution relative to competitors running patched software or alternative implementations that correctly account for block overheads.
From a broader network perspective, this vulnerability can be exploited through mempool manipulation attacks where adversaries strategically place specific transactions into the victim miner's memory pool. By carefully selecting which transactions are available and how they fit within the flawed calculation logic, an attacker can force the template selector to include enough transaction data that, when combined with the unaccounted header and count sizes, pushes the total block size over the consensus limit. This constitutes a denial-of-service vector against specific miners rather than the entire network, as only those using vulnerable Zebra versions are susceptible to having their blocks rejected. Such attacks degrade the efficiency of mining operations and can potentially influence market dynamics by penalizing users of compromised software implementations.
The technical nature of this flaw aligns with CWE-682, which describes Incorrect Calculation, specifically involving arithmetic errors that lead to buffer overflows or logic failures in resource management contexts. Furthermore, from a threat modeling perspective using the MITRE ATT&CK framework for blockchain systems, this vulnerability facilitates actions categorized under Resource Hijacking and Denial of Service via economic exhaustion techniques. The attacker leverages the victim's own computational resources against them by inducing invalid state transitions that result in rejected blocks, thereby consuming energy without achieving consensus validation.
Mitigation strategies require an immediate upgrade to Zebra version 6.1.0 or later, where the block template selector has been corrected to properly subtract header and transaction-count sizes from the available block budget before selecting transactions. Network participants should verify their node versions regularly to ensure compliance with updated consensus logic. Additionally, monitoring tools can be configured to detect patterns of mempool manipulation that attempt to exploit size calculation errors, allowing for proactive identification of potential attack vectors targeting mining infrastructure. Ensuring strict adherence to protocol-defined structural limits is essential for maintaining the integrity and economic fairness of proof-of-work networks.