Zcash Zebra EUVD-2026-91436

Exploitation requires the target to be running ZcashFoundation Zebra before 6.1.0 as a reachable node on the Zcash peer-to-peer network, accepting inbound peer connections and pushed (unsolicited) transactions. The specific trigger is sending transactions bearing invalid Orchard proofs, which are routed into the shared halo2 batch verifier; the key enabling flaw is that these invalid pushed transactions are NOT misbehavior-scored, so the attacker is never penalized or disconnected. No authentication is required (PR:N) and no special non-default configuration is needed beyond normal network participation. Limiting factors: impact is confined to processing throughput degradation (roughly 7x slowdown) rather than crash or compromise, and a node not exposed to arbitrary inbound peers (e.g., restricted/allowlisted peering) reduces exposure.

This is a moderate-severity availability-only issue, correctly rated 6.9 (CVSS 4.0) by the vendor-supplied vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L (network, low complexity, no auth, no user interaction, low availability impact and zero confidentiality/integrity impact). The signals are internally consistent: a remote unauthenticated attacker can reliably trigger it, but the only consequence is degraded block-processing throughput (roughly 7x slower), not node crash, data loss, or fund theft - hence VA:L rather than VA:H. No EPSS score, CISA KEV listing, or public POC is present in the provided data, so this is not confirmed as actively exploited and there is no evidence of widespread opportunistic exploitation; it should be treated as 'no public exploit identified at time of analysis.' The design-level nature of the flaw (any peer can poison the shared halo2 batch verifier without being misbehavior-scored) means exploitation is cheap and does not require special skill, which raises practical concern despite the bounded impact. Net: a legitimate operational-resilience priority for Zcash node operators running Zebra, but not an emergency relative to code-execution or data-exposure CVEs; patch promptly rather than panic-patch. Note that EPSS data is absent, so probability-of-exploitation cannot be quantified from the inputs.

A malicious peer connects to a Zebra node (before 6.1.0) over the normal unauthenticated p2p network and repeatedly pushes transactions containing invalid Orchard proofs. Because these pushed transactions do not incur misbehavior scoring, the attacker can continuously poison the shared halo2 batch verifier, forcing legitimate block proofs off the fast batch path onto slow individual verification and degrading block processing by roughly sevenfold. No public exploit code is identified in the provided data, but the attack requires no authentication, no user interaction, and only low complexity.