Zcash Zebra CVE-2026-123557

Exploitation requires all of: the target runs zebrad before 7.0.0 (specifically 6.4.2 or earlier, or 7.0.0-rc.0); a release build, which is the default for published binaries and Docker images and sets panic=abort so an assertion terminates the process; and a node that accepts or makes P2P connections to untrusted peers (the default). The attacker needs only an ordinary post-handshake P2P connection - no credentials (PR:N). Limiting factors: the trigger is a timing race (CVSS AC:H/AT:P) in which a pending outbound socket write must overlap a peer disconnection, and the confirmed trigger path applies only while the node is syncing (more than 1,000 blocks behind the network tip), though the vendor notes other disconnection paths reaching the same window were not ruled out. There is no configuration option that removes the trigger; only upgrading to 7.0.0 does. A process supervisor with automatic restart (e.g. systemd Restart=on-failure or a container restart policy) limits outage duration but does not prevent the abort.

This is a genuine but bounded availability risk, not a high-severity emergency. The signals are internally consistent: the CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N) describes an unauthenticated, network-reachable flaw whose exploitation is gated by high attack complexity and a specific attack requirement - a timing window where a pending outbound socket write overlaps a peer disconnection - and the only impact is availability (VA:H; VC:N/VI:N) with no scope change. The GHSA advisory corroborates this precisely: no consensus, funds, privacy, or persistent-state impact, and the node recovers on restart. The vuln.today decision label is 'this_week' (not act_now/emergency), which matches a serious DoS without active exploitation. Exploitation status: no public exploit identified at time of analysis - there is no CISA KEV listing, no EPSS score, and no PoC/exploit reference in the input; the advisory credits two independent researcher rediscoveries but does not publish working exploit code. The practical priority is driven by the fact that the defect is in the connection request lifecycle (reachable on multiple disconnection paths, not just the confirmed syncing-stall path) and affects default release builds, so every node on an affected version should be treated as exposed. Missing data to note: EPSS and KEV are absent (not errors, just unavailable), and no independent confirmation of exploitation in the wild exists.

A malicious peer completes a normal P2P handshake with a syncing zebrad node, returns empty FindBlocks/FindHeaders replies to be counted as stalls, and stops reading from its socket so an outbound send blocks. When the peer set removes the stalled peer while that write is still pending, an unresolved MustUseClientResponseSender is dropped, firing an assertion that aborts the release build (panic=abort) and terminates the node. No public exploit code is identified; the race is timing-dependent (CVSS AC:H/AT:P), so a trigger may require repeated attempts.