Zcash Zebra EUVD-2026-119445

Exploitable only when the target runs zebrad 6.4.2 or earlier (or 7.0.0-rc.0) with checkpoint_sync=true (the default) AND is performing initial sync or resync within roughly 3,000 blocks below the final compiled checkpoint; nodes already past the final checkpoint or finished syncing are not exposed. The attacker must be an admitted P2P peer that gets selected to serve just one block body in that recording window - no race or authentication is needed (PR:N, AC:L), and per the advisory the delivery needs no timing precision. Limiting factors that reduce real-world risk: the stale markers live only in memory so a restart fully recovers, impact is a single syncing node per delivery, there is no persisted bad state/fork/funds impact, and zebrad 7.0.0 is not affected.

This is a remote, unauthenticated, availability-only denial-of-service against the Zebra Zcash node, and the signals are internally consistent. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, VC:N/VI:N/VA:H, score 8.7) and the vendor's CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) both confirm no confidentiality or integrity impact - only availability. The higher 4.0 number reflects scoring-model differences, not a worse real-world outcome; the practical impact is identical. SSVC-style signals temper the urgency: vuln.today assigns 'this_week' (not act_now/emergency), and the impact is narrow - one syncing node per delivery, no persisted invalid state, no fork, no funds affected, and a simple restart recovers progress. No EPSS score was provided and the CVE is not on CISA KEV, so there is no evidence of active exploitation; exploitation status is 'no public exploit identified at time of analysis.' The exposure window is also inherently limited: only nodes mid-sync within ~3,000 blocks of the final checkpoint are affected, and already-synced nodes are not exposed. Net assessment: a credible, low-complexity DoS worth patching on a normal cycle, but not a high-urgency widespread threat - the combination of availability-only impact, niche product footprint, and no exploitation evidence keeps real-world priority moderate despite the 8.7 headline number.

A node operator starts or resyncs zebrad (pre-7.0.0, default checkpoint_sync=true) and reaches within ~3,000 blocks of the final compiled checkpoint. An admitted but malicious P2P peer is selected to serve one block body and returns a body carrying the expected block hash but forged authorizing data; because the hash is recorded in the sent-hash set before the deferred authorizing-data check rejects it, the node believes it already has that block and everything above it and stops requesting them, stalling sync until restart. A production-stack reproducer was described by the reporter, but no public working exploit code is referenced in the available data.