Zcash Zebra CVE-2026-104432

Exploitation requires the node to expose and have operators depend on the /ready readiness endpoint for routing/health decisions, plus a sync peer that returns a FindBlocks response containing only the single next-block hash - the exact condition that ChainSync::obtain_tips mishandles as exceptional, yielding a zero-length sync sample. The flaw affects Zebra versions before 6.3.0 (CPE zcashfoundation:zebra). Per CVSS AV:N/AC:L/PR:N/UI:N it needs no authentication or user interaction, but its practical impact is strictly limited to environments that trust /ready as a signal; operators who do not gate traffic on /ready experience no meaningful consequence beyond an inaccurate status report.

This is a genuine but modest-severity reliability/correctness defect, not a high-impact security crisis. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L) scores 6.9 (Medium) and is internally consistent with the description: a remote, unauthenticated peer can trigger the condition with low complexity, but the only impact is a low-level availability/integrity-of-signal degradation (VA:L) - no confidentiality (VC:N) or data integrity (VI:N) compromise. No EPSS score was supplied, the CVE is NOT on the CISA KEV list, and no public exploit is referenced, so there is no evidence of active or widespread exploitation - this is a design/logic flaw surfaced by a vendor advisory (Zcash Foundation GHSA) and VulnCheck research rather than observed attacks. The real-world priority is low-to-moderate and highly conditional: it only matters to operators who rely on Zebra's /ready endpoint for orchestration/load-balancing health decisions. Note a labeling conflict: the input tags this as 'Information Disclosure', which contradicts the CVSS vector (VC:N, no confidentiality impact) and the description (a false-readiness/availability issue) - the tag appears incorrect.

A node operator fronts Zebra with a load balancer or Kubernetes liveness/readiness probe that queries the /ready endpoint. A peer (potentially attacker-controlled) returns a FindBlocks response containing only the single next-block hash; ChainSync::obtain_tips discards this as an exceptional condition, producing a zero-length sync sample so the node reports close-to-tip and /ready returns 200 OK while it is actually behind the chain tip. No public exploit code is referenced; triggering the condition requires only normal peer-to-peer interaction.