{"id":"CVE-2026-104436","aliases":["EUVD-2026-91446","GHSA-443g-gwgp-49x4","GHSA-4m38-rccq-j8gv"],"status":"published","title":"Zebra before 4.5.0 CPU Amplification via Uncapped getblocks/getheaders Locator Length","description":"Zebra before 4.5.0 contains an uncontrolled resource consumption vulnerability that allows remote P2P peers to exhaust blocking-pool threads by sending oversized block locator vectors. Attackers can send getblocks or getheaders messages with up to 65,535 locator hashes, triggering per-hash chain lookups that degrade block validation, RPC, and mempool performance.","severity":{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00273,"percentile":0.19916,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-770"],"published":"2026-07-02T19:34:21Z","modified":"2026-10-31T02:30:31Z","fixes":[{"ecosystem":"crates.io","package":"zebrad","fixed_in":["4.5.0"],"sources":["ghsa","osv"]},{"ecosystem":"crates.io","package":"zebra-chain","fixed_in":["8.0.0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"crates.io","package":"zebrad","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.5.0"}]}]},{"source":"ghsa","ecosystem":"crates.io","package":"zebra-chain","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"8.0.0"}]}]},{"source":"osv","ecosystem":"crates.io","package":"zebrad","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"4.5.0"}]}]},{"source":"osv","ecosystem":"crates.io","package":"zebra-chain","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"8.0.0"}]}]}],"products":[{"vendor":"zcashfoundation","product":"zebra"},{"vendor":"zcashfoundation","product":"zebra-chain"}],"references":[{"url":"https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-443g-gwgp-49x4","tags":["vendor-advisory","advisory","web"]},{"url":"https://www.vulncheck.com/advisories/zebra-before-4.5.0-cpu-amplification-via-uncapped-getblocks-getheaders-locator-length","tags":["third-party-advisory","advisory"]},{"url":"https://github.com/ZcashFoundation/zebra/pull/10570","tags":["web"]},{"url":"https://github.com/ZcashFoundation/zebra/commit/8981a1b95d4807cad99e5bb3b94fc8bc723ac033","tags":["web"]},{"url":"https://github.com/advisories/GHSA-443g-gwgp-49x4"},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-104436","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-4m38-rccq-j8gv"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/104xxx/CVE-2026-104436.json","tags":["advisory"]},{"url":"https://github.com/ZcashFoundation/zebra","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-104436","title":"Zebra before 4.5.0 CPU Amplification via Uncapped getblocks/getheaders Locator Length","description":"Zebra before 4.5.0 contains an uncontrolled resource consumption vulnerability that allows remote P2P peers to exhaust blocking-pool threads by sending oversized block locator vectors. Attackers can send getblocks or getheaders messages with up to 65,535 locator hashes, triggering per-hash chain lookups that degrade block validation, RPC, and mempool performance.","status":"published","published":"2026-10-02T11:38:13.172Z","modified":"2026-10-29T21:15:28.872Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"medium","assessor":"cna"},{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"low","assessor":"cna"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T14:20:09.448255Z"}],"euvd":[{"id":"EUVD-2026-91446","description":"Zebra before 4.5.0 contains an uncontrolled resource consumption vulnerability that allows remote P2P peers to exhaust blocking-pool threads by sending oversized block locator vectors. Attackers can send getblocks or getheaders messages with up to 65,535 locator hashes, triggering per-hash chain lookups that degrade block validation, RPC, and mempool performance.","status":"published","published":"2026-10-02T11:38:13Z","modified":"2026-10-29T21:15:28Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-02T16:59:14.250155Z"}],"ghsa":[{"id":"GHSA-443g-gwgp-49x4","title":"zebrad vulnerable to getblocks/getheaders locator CPU amplification via uncapped vector length","description":"### Am I affected\n\nYou are affected if:\n\n1. You run `zebrad` up to and including `v4.4.1`.\n2. Your node accepts inbound P2P connections.\n\n### Summary\n\nThe `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.\n\nA 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.\n\n### Details\n\nThe `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.\n\nA 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`.\n\nThe 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.\n\n### Patches\n\nPatched 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.\n\n### Workarounds\n\nNo specific workaround is needed. Existing backpressure mechanisms (load shedding, sequential per-peer message processing, connection limits) constrain the practical impact.\n\n### Impact\n\nUnder 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.\n\n### Credit\n\nVulnerability 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`.","status":"published","published":"2026-07-02T19:34:21Z","modified":"2026-07-02T19:34:21Z","cvss":[{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"low"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T14:40:38.48196Z"},{"id":"GHSA-4m38-rccq-j8gv","title":"Zebra before 4.5.0 contains an uncontrolled resource consumption vulnerability that allows remote...","description":"Zebra before 4.5.0 contains an uncontrolled resource consumption vulnerability that allows remote P2P peers to exhaust blocking-pool threads by sending oversized block locator vectors. Attackers can send getblocks or getheaders messages with up to 65,535 locator hashes, triggering per-hash chain lookups that degrade block validation, RPC, and mempool performance.","status":"published","published":"2026-10-02T12:31:15Z","modified":"2026-10-02T12:31:21Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium"},{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"low"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T15:12:43.051947Z"}],"nvd":[{"id":"CVE-2026-104436","description":"Zebra before 4.5.0 contains an uncontrolled resource consumption vulnerability that allows remote P2P peers to exhaust blocking-pool threads by sending oversized block locator vectors. Attackers can send getblocks or getheaders messages with up to 65,535 locator hashes, triggering per-hash chain lookups that degrade block validation, RPC, and mempool performance.","status":"published","published":"2026-10-02T12:17:14.21Z","modified":"2026-10-29T21:17:08.69Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium","assessor":"secondary"},{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"low","assessor":"secondary"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T14:12:53.41762Z"}],"osv":[{"id":"CVE-2026-104436","title":"Zebra before 4.5.0 CPU Amplification via Uncapped getblocks/getheaders Locator Length","description":"Zebra before 4.5.0 contains an uncontrolled resource consumption vulnerability that allows remote P2P peers to exhaust blocking-pool threads by sending oversized block locator vectors. Attackers can send getblocks or getheaders messages with up to 65,535 locator hashes, triggering per-hash chain lookups that degrade block validation, RPC, and mempool performance.","status":"published","published":"2026-10-02T11:38:13.172Z","modified":"2026-10-31T02:30:31.557505913Z","cvss":[{"version":"4.0","score":6.3,"vector":"CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T15:44:54.236592Z"},{"id":"GHSA-443g-gwgp-49x4","title":"zebrad vulnerable to getblocks/getheaders locator CPU amplification via uncapped vector length","description":"### Am I affected\n\nYou are affected if:\n\n1. You run `zebrad` up to and including `v4.4.1`.\n2. Your node accepts inbound P2P connections.\n\n### Summary\n\nThe `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.\n\nA 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.\n\n### Details\n\nThe `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.\n\nA 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`.\n\nThe 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.\n\n### Patches\n\nPatched 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.\n\n### Workarounds\n\nNo specific workaround is needed. Existing backpressure mechanisms (load shedding, sequential per-peer message processing, connection limits) constrain the practical impact.\n\n### Impact\n\nUnder 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.\n\n### Credit\n\nVulnerability 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`.","status":"published","published":"2026-07-02T19:34:21Z","modified":"2026-10-03T03:56:03.280851902Z","cvss":[{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"low"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T15:46:36.434231Z"}]}}