zebrad vulnerable to getblocks/getheaders locator CPU amplification via uncapped vector length
### Am I affected You are affected if: 1. You run `zebrad` up to and including `v4.4.1`. 2. Your node accepts inbound P2P connections. ### Summary The `read_getblocks` and `read_getheaders` codec paths accepted block locator vectors up to approximately 65,535 entries (the generic `TrustedPreallocate` ceiling derived from `MAX_PROTOCOL_MESSAGE_LEN`), rather than the protocol-specification limit of 101 entries (matching zcashd's `MAX_LOCATOR_SZ`). Each entry in the locator vector triggers a per-hash chain lookup (`HashMap::contains_key` + `RocksDB::contains_hash`) in `find_chain_intersection` on a tokio blocking-pool thread. A single maximally-sized `getblocks` message occupies one blocking-pool thread for approximately 10–65ms. Under sustained load from multiple peers, this can degrade state-read performance for block validation, RPC, and mempool lookups. ### Details The `read_headers` codec path already implements the correct pattern: it reads the CompactSize count, validates against `MAX_HEADERS_PER_MESSAGE = 160` before deserialization, and rejects oversized messages. The `read_getblocks` and `read_getheaders` paths were missing this pre-deserialization count check and instead relied on the generic `block::Hash::max_allocation()` bound, which allows `(MAX_PROTOCOL_MESSAGE_LEN - 1) / 32 = 65,535` hashes. A legitimate block locator is logarithmic in chain length (approximately 30 hashes for the current ~3M-block Zcash chain). Zebra's own send-side cap is `MAX_FIND_BLOCK_HASHES_RESULTS = 500`. The practical impact requires significant attacker bandwidth (approximately 2 MiB per request) and multiple Sybil peers to meaningfully degrade the blocking pool, which limits real-world exploitability. ### Patches Patched in Zebra 4.4.2. The fix caps `block::Hash::max_allocation()` at `MAX_BLOCK_LOCATOR_LENGTH = 101`, matching zcashd's `MAX_LOCATOR_SZ`. This causes the deserializer to reject oversized locators before any allocation or iteration occurs. ### Workarounds No specific workaround is needed. Existing backpressure mechanisms (load shedding, sequential per-peer message processing, connection limits) constrain the practical impact. ### Impact Under sustained load from multiple Sybil peers, oversized locator vectors can occupy blocking-pool threads and degrade state-read performance. The effect is bounded by connection limits and requires significant attacker bandwidth. ### Credit Vulnerability identified by `@dingledropper`, who submitted the fix in [PR #10570](https://github.com/ZcashFoundation/zebra/pull/10570). Downstream CPU/blocking-pool impact analysis contributed by `@ouicate`.
AI Analysis
Technical Summary
The zebrad client versions up to and including 4.4.1 accept getblocks and getheaders messages with block locator vectors far exceeding the protocol-specified maximum of 101 entries, allowing up to 65,535 entries due to missing pre-deserialization count checks. Each locator entry triggers a costly chain lookup on a blocking-pool thread, causing CPU amplification and potential degradation of state-read performance under sustained load from multiple peers. The vulnerability is mitigated by the patch in zebrad 4.4.2, which caps the maximum locator vector length to 101, rejecting oversized messages before processing. Exploitation requires high bandwidth and multiple Sybil peers, and existing connection limits and load shedding reduce practical exploitability.
Potential Impact
The vulnerability can cause blocking-pool threads to be occupied for 10–65ms per oversized getblocks message, degrading performance of block validation, RPC, and mempool lookups under sustained attack from multiple peers. There is no direct confidentiality, integrity, or availability compromise beyond degraded performance. The impact is limited by connection limits and the bandwidth required to send large messages, resulting in a low severity impact.
Mitigation Recommendations
A patch is available in zebrad version 4.4.2 that enforces the correct maximum locator vector length of 101 entries, rejecting oversized messages before deserialization. Users should upgrade to version 4.4.2 or later to remediate this vulnerability. No additional workarounds are necessary as existing backpressure and connection limit mechanisms constrain the impact.
zebrad vulnerable to getblocks/getheaders locator CPU amplification via uncapped vector length
Description
### Am I affected You are affected if: 1. You run `zebrad` up to and including `v4.4.1`. 2. Your node accepts inbound P2P connections. ### Summary The `read_getblocks` and `read_getheaders` codec paths accepted block locator vectors up to approximately 65,535 entries (the generic `TrustedPreallocate` ceiling derived from `MAX_PROTOCOL_MESSAGE_LEN`), rather than the protocol-specification limit of 101 entries (matching zcashd's `MAX_LOCATOR_SZ`). Each entry in the locator vector triggers a per-hash chain lookup (`HashMap::contains_key` + `RocksDB::contains_hash`) in `find_chain_intersection` on a tokio blocking-pool thread. A single maximally-sized `getblocks` message occupies one blocking-pool thread for approximately 10–65ms. Under sustained load from multiple peers, this can degrade state-read performance for block validation, RPC, and mempool lookups. ### Details The `read_headers` codec path already implements the correct pattern: it reads the CompactSize count, validates against `MAX_HEADERS_PER_MESSAGE = 160` before deserialization, and rejects oversized messages. The `read_getblocks` and `read_getheaders` paths were missing this pre-deserialization count check and instead relied on the generic `block::Hash::max_allocation()` bound, which allows `(MAX_PROTOCOL_MESSAGE_LEN - 1) / 32 = 65,535` hashes. A legitimate block locator is logarithmic in chain length (approximately 30 hashes for the current ~3M-block Zcash chain). Zebra's own send-side cap is `MAX_FIND_BLOCK_HASHES_RESULTS = 500`. The practical impact requires significant attacker bandwidth (approximately 2 MiB per request) and multiple Sybil peers to meaningfully degrade the blocking pool, which limits real-world exploitability. ### Patches Patched in Zebra 4.4.2. The fix caps `block::Hash::max_allocation()` at `MAX_BLOCK_LOCATOR_LENGTH = 101`, matching zcashd's `MAX_LOCATOR_SZ`. This causes the deserializer to reject oversized locators before any allocation or iteration occurs. ### Workarounds No specific workaround is needed. Existing backpressure mechanisms (load shedding, sequential per-peer message processing, connection limits) constrain the practical impact. ### Impact Under sustained load from multiple Sybil peers, oversized locator vectors can occupy blocking-pool threads and degrade state-read performance. The effect is bounded by connection limits and requires significant attacker bandwidth. ### Credit Vulnerability identified by `@dingledropper`, who submitted the fix in [PR #10570](https://github.com/ZcashFoundation/zebra/pull/10570). Downstream CPU/blocking-pool impact analysis contributed by `@ouicate`.
CVSS v3.1
Score 3.7low
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The zebrad client versions up to and including 4.4.1 accept getblocks and getheaders messages with block locator vectors far exceeding the protocol-specified maximum of 101 entries, allowing up to 65,535 entries due to missing pre-deserialization count checks. Each locator entry triggers a costly chain lookup on a blocking-pool thread, causing CPU amplification and potential degradation of state-read performance under sustained load from multiple peers. The vulnerability is mitigated by the patch in zebrad 4.4.2, which caps the maximum locator vector length to 101, rejecting oversized messages before processing. Exploitation requires high bandwidth and multiple Sybil peers, and existing connection limits and load shedding reduce practical exploitability.
Potential Impact
The vulnerability can cause blocking-pool threads to be occupied for 10–65ms per oversized getblocks message, degrading performance of block validation, RPC, and mempool lookups under sustained attack from multiple peers. There is no direct confidentiality, integrity, or availability compromise beyond degraded performance. The impact is limited by connection limits and the bandwidth required to send large messages, resulting in a low severity impact.
Mitigation Recommendations
A patch is available in zebrad version 4.4.2 that enforces the correct maximum locator vector length of 101 entries, rejecting oversized messages before deserialization. Users should upgrade to version 4.4.2 or later to remediate this vulnerability. No additional workarounds are necessary as existing backpressure and connection limit mechanisms constrain the impact.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-443g-gwgp-49x4
- Osv Schema Version
- 1.4.0
- Aliases
- []
- Ecosystems
- ["crates.io"]
- Database Specific Severity
- LOW
- Cvss Version
- 3.1
Threat ID: 6a46ecb727e9c7971943ca32
Added to database: 07/02/2026, 22:56:55 UTC
Last enriched: 07/02/2026, 23:12:13 UTC
Last updated: 07/31/2026, 12:27:30 UTC
Views: 60
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.