Zcash Zebra CVE-2026-104436

Exploitable only against a zebrad node (<=4.4.1 / before 4.5.0) that accepts inbound P2P connections; the attacker sends getblocks or getheaders messages whose block-locator vector exceeds the protocol's 101-entry limit (up to 65,535 hashes via the generic MAX_PROTOCOL_MESSAGE_LEN-derived bound). Meaningful impact additionally requires significant attacker bandwidth (~2 MiB per request) and multiple sustained/Sybil peers. Limiting factors that reduce real-world risk: existing backpressure mechanisms (load shedding, sequential per-peer message processing, connection limits), and that nodes not accepting inbound connections are unaffected; impact is performance degradation, not full node crash.

This is a genuine but modest-priority issue best characterized as a resource-exhaustion/CPU-amplification flaw rather than a critical threat. The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N) scores 6.3 (Medium): network-reachable and unauthenticated, but with HIGH attack complexity and a present Attack Requirement (AT:P), and only LOW availability impact (VA:L) with no confidentiality or integrity impact. These signals align well with the vendor advisory, which explicitly states real-world exploitability is limited - degradation (not outage) requires ~2 MiB per request, sustained load, and multiple Sybil peers, and is further bounded by existing backpressure (load shedding, sequential per-peer processing, connection limits). There is no EPSS score, KEV listing, or public exploit provided in the input, so the status is no public exploit identified at time of analysis and no confirmed exploitation. The AC:H/AT:P metrics are consistent with the description's emphasis on attacker bandwidth and Sybil requirements, so no signals conflict. Net: a legitimately fixable node-stability bug for Zcash/Zebra operators, but not an urgent, widely-weaponizable vulnerability.

An attacker establishes multiple inbound P2P (Sybil) connections to a public-facing zebrad node (<=4.4.1) and sends a stream of maximally-sized getblocks/getheaders messages, each carrying up to 65,535 locator hashes instead of the ~101 the protocol expects. Each message occupies a tokio blocking-pool thread for roughly 10-65ms performing per-hash chain lookups, and sustained parallel requests degrade state-read performance for block validation, RPC, and mempool. No public exploit code is identified in the provided data; exploitation requires significant attacker bandwidth.