Zcash Zebra EUVD-2026-119441

No configuration change is required: the node must be running affected zebrad (4.5.0-6.4.2 or 7.0.0-rc.0) with P2P networking enabled and the mempool active (default once near the chain tip) and accepting transaction relay from peers (default). The exploitable window is narrow and timing-bound - the victim node must be exactly one block behind a relaying peer at the moment a lock-time-boundary transaction arrives, so the attacker must broadcast transactions locked to the current height immediately after each new block and reach nodes that have already committed it. Limiting factors: the condition self-heals the instant the lagging node receives the next block, impact is confined to peer connectivity (no crash, consensus divergence, state corruption, or loss of funds), and mining/RPC/wallet configuration is irrelevant. Severity of persistence varies by branch: 6.4.x bans an IP group for 24 hours, while 4.5.0-6.3.x hold the ban per IP until the node restarts.

This is a genuine but bounded availability/peer-reachability issue, not a high-impact priority. All impact signals point one direction: the input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) scores VA:L with VC:N/VI:N and no subsequent-system impact, and the vendor GHSA advisory's CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L = 5.3) agrees - the only impact is availability of peer connections. Note a numeric discrepancy worth flagging: the input lists CVSS 6.9 while the ZcashFoundation advisory rates it 5.3; both are Medium, so the qualitative conclusion is unchanged, but the 6.9 figure is not corroborated by the vendor. No CISA KEV entry is present and no EPSS score was supplied, so there is no evidence of active or widespread exploitation; the vuln.today decision label is 'this_month' (not act_now/emergency). No weaponized public exploit code is indicated - an independent public bug report (#11623) and a private two-node reproduction exist, but these are reports of the defect, not off-the-shelf exploit code. Net: a real protection-mechanism-failure defect that lets an attacker erode an honest node's peer set, but it does not touch funds, consensus, or node liveness and self-heals on the next block, so it warrants scheduled patching rather than emergency response.

An attacker broadcasts transactions whose lock time is satisfied only at the current tip height immediately after each new block is mined, sending them to peers that have already committed the block. Nodes that are one block behind reject the relayed transaction with a lock-time error and ban the honest relaying peer (24 hours on 6.4.x, until restart on 4.5.0-6.3.x), repeatedly stripping well-connected honest nodes of peers. No public exploit code is identified; an independent public report (#11623) and a private two-node reproduction document the behavior.