Executive brief
Zebra, a Zcash node implementation, is vulnerable to a resource exhaustion issue when processing certain peer-to-peer messages. An attacker can send specially crafted network requests that force the node to perform excessive database lookups, potentially slowing down block validation and other critical services. While difficult to exploit due to high bandwidth requirements, this could lead to degraded performance for node operators.
Technical details
The read_getblocks and read_getheaders codec paths in zebrad failed to enforce the protocol-specified limit of 101 entries for block locator vectors, instead allowing up to 65,535 entries. Each entry in an oversized vector triggers a per-hash chain lookup (HashMap and RocksDB operations) on a tokio blocking-pool thread. An attacker can exploit this by sending maximally-sized messages to occupy blocking-pool threads for 10–65ms per request, potentially leading to a denial-of-service (DoS) through resource exhaustion. The vulnerability is mitigated by the high bandwidth required (2 MiB per request) and existing backpressure mechanisms. The fix, introduced in Zebra 4.4.2/4.5.0, caps the maximum allocation for block hashes at 101.
Affected products
- ZcashFoundation zebrad < 4.5.0
- ZcashFoundation zebra-chain < 8.0.0
Timeline
- 2026-05-29: patched: Fix submitted in PR #10570
- 2026-07-02: advisory: GitHub Advisory published