Zcash Zebra EUVD-2026-119443

Exploitable only against a node running zebrad 6.4.2 or earlier, or 7.0.0-rc.0, that is actively syncing through a checkpoint range at NU5 activation height or later (on Mainnet, heights 1,687,104 up to the final checkpoint) - i.e., a new node, a from-scratch re-sync, or a node restarting from a cached state below the final checkpoint. It requires checkpoint_sync enabled (the default) and the node downloading blocks from untrusted peers (the default on Mainnet and Testnet); no configuration change enables or disables the flaw, so default configurations are affected. The attacker needs no proof of work and no keys but must be asked for two specific blocks while a checkpoint range is pending, which a peer serving part of a full sync's block requests is likely to be. Limiting factors: nodes already past the final checkpoint are NOT affected; impact is confined to stalling sync progress (recoverable by restart, but re-stallable); and syncing from a trusted cached state already past the final checkpoint avoids the exposure.

Signals align on a genuine but bounded availability-only threat. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H, 8.7) and the vendor GHSA 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) agree: network-reachable, low complexity, no privileges, no user interaction, with impact confined to availability (no confidentiality/integrity effect). The vuln.today decision label is 'this_week' rather than act_now/emergency. There is no CISA KEV listing and no EPSS score in the supplied data, so there is no evidence of active or widespread exploitation - treat exploitation probability as unquantified rather than low. A key contrast: raw CVSS reads 'high/critical,' but the vendor advisory explicitly scopes the impact as a recoverable sync stall - no crash, no consensus divergence, no on-disk corruption, no effect on funds, and RPC/peer connections keep working; a restart restores progress (though the attacker can re-stall in a later range). This is therefore a real priority for operators performing initial sync or re-sync of a Zebra node below the final checkpoint, but it is not a loss-of-funds or remote-code-execution class issue. Note the input CWE (CWE-460, Improper Cleanup on Thrown Exception) differs from the vendor's CWE-755/CWE-362; the vendor classification better matches the described cancelled-future/exceptional-condition mechanism.

A single malicious peer that a syncing Zebra node is downloading blocks from serves a forged block body - a genuine block's header and hash but altered authorizing data - together with a second block that makes the sync round fail. The checkpoint verifier advances past the forged block before the state commit rejects it, but the rewind that should realign the verifier is cancelled with the failed round, so the node then rejects honest blocks and makes no further sync progress until an operator restarts it. The reporter built an end-to-end proof of concept through the P2P interface, but no public exploit code is referenced in the available data.