Zebra Denial of Service and Protocol Flaws

Denial of service in the Zcash Foundation's Zebra node (zebrad) 2.3.0 through 7.0.0-rc.0 lets unauthenticated peers exhaust CPU and repeatedly stall block sync by relaying transactions or serving forged v5 block bodies whose transparent scripts fail verification without the peer ever being penalized. The script failure is boxed and downcast to an internal error that scores zero in the misbehavior table, so the 100-point ban never fires on the mempool, block-sync or block-gossip paths. A mempool flood is amplified because transparent signature hashing was quadratic before 7.0.0 (GHSA-j4cw-58mj-7w6v), while a single forged block body cancels the sync round, drops a still-valid hash and idles the syncer for 67 seconds. No public exploit code or CISA KEV entry was identified at time of analysis, the vendor-released patch is Zebra 7.0.0, and impact is bounded: it stops when the attack stops and does not crash the node, corrupt state, or alter what the node accepts into the chain.

Checkpoint sync in Zcash Foundation's Zebra node (zebrad before 7.0.0, including 6.4.2 and 7.0.0-rc.0 and the official Docker images) can be stalled indefinitely by a single unauthenticated remote peer, halting initial sync progress until an operator restarts the process. The peer serves a forged block that keeps a genuine header and hash but carries altered authorizing data, plus a second block that makes the sync round fail, so the verifier's rewind to the state tip is discarded with the cancelled future and honest blocks are afterwards rejected as already verified; the peer can repeat the attack after each restart. Impact is availability only - no crash, consensus divergence, on-disk state corruption or effect on funds - nodes already past the final checkpoint are not affected, no exploitation in the wild is reported, and the upstream advisory documents a reporter-supplied end-to-end proof of concept exercised through the P2P interface.

Denial of service in Zcash Foundation's Zebra (zebrad) releases before 7.0.0 allows any connected peer to stall block verification for minutes by relaying a single invalid transaction constructed with tens of thousands of transparent inputs, forcing quadratic ZIP-244 (and, on the v4 path, ZIP-243) signature-hash recomputation on the shared Rayon verification pool. No authentication or private key is needed - the signatures only have to be well formed enough to pass standardness and DER-encoding checks before failing - and the attacker needs roughly 1-3 ZEC parked in ~39,000 small outputs to satisfy ZIP-317 fee headroom, which is never actually spent and can be reused indefinitely. The flaw is fixed in zebrad 7.0.0 (via zcash_primitives 0.31.0); the reporter demonstrated a working Regtest proof of concept with scaling measurements, but no publicly available exploit code was identified in the available sources, and no CISA KEV entry exists for this issue.

Quadratic CPU cost in the mempool coinbase-maturity check of Zcash's Zebra node (zebrad) allows any connected peer to pin transaction-verification threads and stall block verification, peer handling and sync. Only zebrad 6.4.0, 6.4.1, 6.4.2 and 7.0.0-rc.0 are affected - the regression was introduced by the Transaction newtype refactor in 6.4.0 and is gone again in 7.0.0; 6.3.x and earlier are not affected. An unauthenticated peer needs no funds and no valid signatures: it sends an unsigned transaction with many transparent inputs (empty scriptSigs) and many transparent outputs, which the maturity loop processes at O(inputs × outputs) cost before the standardness check rejects it, and because that rejection is a policy error with a misbehavior score of 0 the peer is never banned and can repeat indefinitely. Impact is availability only, with recovery once the attack stops; no public exploit code has been identified at time of analysis, and there is no KEV listing or EPSS signal in the supplied data.

Initial sync in the Zcash Zebra node (zebrad 6.4.2 and earlier, plus 7.0.0-rc.0) can be stalled indefinitely by a single unauthenticated P2P peer that serves one forged checkpoint block body, causing the node to treat missing blocks as already downloaded and stop requesting them until the process is restarted. Only nodes with checkpoint_sync=true (the default) that are syncing from scratch or resyncing within roughly 3,000 blocks below the final compiled checkpoint are exposed; fully synced nodes and zebrad 7.0.0 are not affected. Impact is availability-only on one syncing node per delivery, with no invalid state written to disk, no chain fork and no funds impact; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor advisory credits multiple independent discoverers who built a working reproducer.

Unauthenticated remote peers can crash a Zcash Foundation Zebra node (zebrad) by exploiting a reachable-assertion race in the P2P connection's request lifecycle. A peer that completes an ordinary handshake, returns empty FindBlocks or FindHeaders replies, and then stops reading its socket can cause its connection to be torn down while an outbound send is still parked; the unresolved MustUseClientResponseSender is dropped, its Drop assertion fires, and because release builds use panic=abort the entire process exits, halting syncing, relaying and RPC until restart. Affected are zebrad builds before 7.0.0 (notably 6.4.2 or earlier and 7.0.0-rc.0) running as release binaries or Docker images with default P2P exposure, with the confirmed trigger path requiring the node to be syncing (more than 1,000 blocks behind tip); the timing-dependent nature (AC:H/AT:P) and availability-only impact keep this a genuine but bounded denial-of-service risk, and no public exploit code was identified at time of analysis, though the vendor has published a full technical advisory and a fixed 7.0.0 release.

Zcash Foundation's Zebra node (zebrad) scores lock-time mempool rejections at the peer-ban threshold, so a node that is one block behind a relaying peer permanently or temporarily bans that honest peer for simply relaying a valid transaction. Affected versions are 4.5.0 through 6.4.2 and 7.0.0-rc.0, and the flaw is remotely reachable without authentication by any peer that can relay or advertise transactions (CVSS 3.1: AV:N/AC:L/PR:N/UI:N/VA:L). The impact is limited to peer-set erosion rather than consensus, funds or node liveness: 6.4.x bans the sender's IP group for 24 hours, while 4.5.0 through 6.3.x hold the ban per IP with no time-based expiry until the node restarts. No public exploit code has been identified at time of analysis, although the issue was independently reported publicly (issue #11623) and the reporter described a complete two-node reproduction.