Zebra Node Remote DoS via Malformed V5 Transaction Deserialization
A logic flaw in Zebra's transaction processing allows remote attackers to crash nodes by sending crafted V5 transactions that pass network deserialization but fail during TxID computation. This PoC demonstrates unauthenticated network-level DoS impact on blockchain infrastructure.
CVE References
Affected
Vulnerability Analysis
Root Cause & Classification This is a Validation Gap Vulnerability (CWE-20: Improper Input Validation). Zebra implements two validation paths for transactions: (1) lenient network-codec deserialization that accepts malformed fields, and (2) strict librustzcash validation during TxID computation. The mismatch causes transactions that pass stage 1 to trigger unhandled panics in stage 2. The flaw exists in lazy evaluation—fields aren't validated until cryptographic operations require them, at which point failure causes process termination rather than graceful rejection.
PoC Significance
This disclosure proves that network-reachable nodes crash reliably from a single crafted PushTransaction P2P message or sendrawtransaction RPC call. The PoC is significant because: (a) it requires zero authentication or prior relationship, (b) availability impact is immediate (single packet = crash), (c) the attack surface is the public P2P port exposed by default, and (d) the condition is deterministic and reproducible across affected versions. No special network conditions or timing are required.
Detection Guidance
Defensive detection should monitor for: (1) Unexpected node shutdowns correlated with incoming P2P tx messages, (2) Log anomalies where transaction deserialization succeeds but TxID computation panics (enable debug logging for zebra_chain::transaction modules), (3) Network signatures matching V5 transaction structures with invalid field combinations (e.g., mismatched serialization lengths, invalid script encoding that passes initial parsing), (4) RPC logs showing sendrawtransaction calls immediately followed by node crashes, (5) Process exit codes indicating panic (typically non-zero unhandled signals). Deploy network-level monitoring to detect repeated crafted transactions targeting port 8233.
Mitigation & Patching
Immediate actions: (1) Upgrade to Zebra 4.3.0+ which implements eager validation before deserialization, (2) Restrict RPC access via firewall rules limiting sendrawtransaction to trusted IPs only, (3) Run behind a load balancer with transaction validation pre-filtering if upgrades are delayed, (4) Monitor node health with automated restart mechanisms to reduce downtime, (5) Disable public P2P access on critical nodes during remediation. The permanent fix validates V5 transaction fields at deserialization time, not lazily at TxID computation time.
Risk Assessment Exploitation likelihood is very high in the wild: (a) this affects entire Zebra node infrastructure (miners, validators, relay nodes), (b) attackers can trivially scan the network for vulnerable nodes on port 8233, (c) no sophisticated tooling is required—a basic Python script sending malformed transactions suffices, (d) botnet-scale DoS campaigns against Zcash network stability are plausible, (e) the attack leaves minimal forensic traces. Threat actors with interest in blockchain infrastructure disruption, competition-driven sabotage, or ransom operations would prioritize this. The fact this was pre-vulnerability in active mainnet suggests potential prior exploitation.
Sources