Quick answers
- Is This vulnerability exploited in the wild?
- No. Junglewise Threat Intelligence has no report of This vulnerability being exploited in the wild.
- How severe is This vulnerability?
- Low severity, with a CVSS score of 3.7, published 2 July 2026.
- Which products and versions are affected?
- zebra-chain (crates.io) < 8.0.0; zebrad (crates.io) < 4.5.0.
- Is there a fix for This vulnerability?
- A patch was published on 2026-05-29: Fix submitted in PR #10570 Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
- How is This vulnerability attacked?
- It is attacked over the network, in a software library.
- Am I affected?
- Check whether you run zebra-chain (crates.io) or zebrad (crates.io) at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.
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