Zcash Zebra EUVD-2026-91431

No authentication or user interaction is required: any peer able to establish a Zcash P2P connection to a vulnerable Zebra node (versions 0 through before 6.3.0) can exploit this by sending invalid gossiped blocks. The specific trigger is the inbound cleanup step incorrectly downcasting RouterError to VerifyBlockError, which discards the misbehavior score and prevents the normal peer-banning protection from applying. Exploitation is limited to an availability/resource-consumption effect (forcing repeated block download and Equihash verification) - there is no path to data disclosure, code execution, or integrity compromise, and the node must be running a pre-6.3.0 version exposed to inbound/peer gossip traffic.

This is a medium-severity resource-exhaustion / protection-mechanism-failure issue (CVSS 4.0 base 6.9) rather than a critical priority. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) shows network-reachable, low-complexity, unauthenticated exploitation with no special attack requirement, which is consistent with the description of unauthenticated peers abusing the gossip path. Critically, the only impact metric set is VA:L (low availability) with VC:N/VI:N/VA being availability-only - there is NO confidentiality or integrity impact, which directly contradicts the 'Information Disclosure' tag in the input (see data_quality_flags). No EPSS score, KEV listing, or POC flag was supplied: the finding was reported by VulnCheck and carries a vendor GHSA advisory, so it is a credible but not actively-exploited issue - no public exploit identified at time of analysis. The real-world risk is a targeted availability/CPU-exhaustion nuisance against Zebra nodes (repeated forced Equihash verification without ban), not a widespread high-impact threat. Given Zebra's niche footprint as an alternative Zcash node implementation, this is a 'patch in normal cycle' item, not an emergency, despite the network/unauthenticated vector.

A malicious peer connects to a Zebra node (before 6.3.0) over the normal P2P network and repeatedly gossips invalid blocks. Because the inbound cleanup path downcasts RouterError to VerifyBlockError and discards the misbehavior score, the peer is never banned and can keep forcing the node to download blocks and run expensive Equihash verification, degrading availability. No public exploit code was identified in the provided data, but the preconditions are trivial (network access, no authentication).