EUVD-2026-61167
GHSA-w834-cf6p-9m9w
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AV:N because the attack is delivered via a broadcast Zcash block; AC:H because exploitation requires both mining hardware and ~1,100-2,100 ZEC capital; PR:N at the network layer; availability-only impact with no confidentiality or integrity effect.
Primary rating from Vendor (https://github.com/ZcashFoundation/zebra).
CVSS VectorVendor: https://github.com/ZcashFoundation/zebra
Lifecycle Timeline
2DescriptionCVE.org
Am I affected
You are affected if:
- You run
zebradup to and includingv4.4.1. - Your node processes blocks on any Zcash network.
Summary
The finalized transparent address balance writer processes all newly-created outputs (credits) before processing spent outputs (debits) within the same block. A consensus-valid block containing a long chain of same-address transparent self-spends can cause the intermediate per-address balance during the credit pass to exceed MAX_MONEY, triggering a panic in the finalized state writer.
Because the triggering block is consensus-valid (zcashd accepts it), the panic recurs on restart when the node re-encounters the same block. This creates a persistent chain halt that can only be resolved by a software patch.
Details
The finalized state writer at zebra-state/src/service/finalized_state/zebra_db/transparent.rs iterates all transaction outputs in a block and credits them to per-address balances before iterating inputs and debiting spent outputs. When a block contains many transparent self-spends to the same address, the intermediate credit-only balance can exceed the MAX_MONEY supply cap even though the final net balance (credits minus debits) is valid.
The code panics on the intermediate overflow via .expect() on the balance addition. Under Zebra's panic = "abort" release profile, this terminates the process. On restart, the node re-downloads and re-processes the same consensus-valid block, triggering the same panic.
An attacker with approximately 1,100-2,100 ZEC and mining capability can construct a block that permanently halts all Zebra nodes. The attacker recovers their capital (the self-spends return funds to the same address), so the net cost is the mining effort only.
Patches
Patched in Zebra 4.4.2. The fix processes credits and debits together per transaction rather than all credits then all debits, matching zcashd's approach.
Workarounds
No workaround is available. Upgrade to Zebra 4.4.2.
Impact
A single consensus-valid mined block can permanently halt all Zebra nodes on the network. The halt persists across restarts. Recovery requires deploying a patched version. Downstream consumers (light wallets, exchanges, mining infrastructure) lose service for the duration of the halt.
Credit
Reported by @sangsoo-osec.
AnalysisAI
Persistent denial-of-service in zebrad (Zcash Foundation's Zcash node) up to and including v4.4.1 allows an attacker with mining capability and approximately 1,100-2,100 ZEC to permanently halt all Zebra nodes on the network by mining a single consensus-valid block. The block exploits a credit-before-debit processing order in the finalized transparent state writer, causing an intermediate per-address balance to overflow the MAX_MONEY cap and trigger a Rust panic-abort. Because the triggering block is consensus-valid, the panic recurs on every restart, creating an unrecoverable halt until the node is patched. No public exploit or KEV listing has been identified at time of analysis.
Technical ContextAI
zebrad is the Rust-based Zcash full-node implementation maintained by the Zcash Foundation (pkg:rust/zebrad, pkg:rust/zebra-state). The vulnerable code resides in the finalized state writer at zebra-state/src/service/finalized_state/zebra_db/transparent.rs. The root cause (CWE-248: Uncaught Exception) is a processing-order defect: all transaction outputs (credits) across an entire block are applied to per-address balances before any transaction inputs (debits) are processed. A block containing a long chain of transparent self-spends to the same address causes that address's intermediate credit-only balance to transiently exceed the protocol-defined MAX_MONEY supply cap. The balance addition uses Rust's .expect() combinator, which panics on overflow. Under Zebra's release profile (panic = 'abort'), this terminates the process rather than unwinding. Because the block is fully consensus-valid - zcashd processes it without issue - Zebra re-downloads and re-applies the same block on every restart, making the halt permanent until a patched binary is deployed. The tagged 'Buffer Overflow' classification is a loose approximation; the precise root cause is an arithmetic overflow of an internal accumulator that is never caught.
RemediationAI
Upgrade to Zebra 4.4.2, the vendor-confirmed patched release. The fix restructures the finalized state writer to process credits and debits together per transaction rather than iterating all credits then all debits block-wide, matching zcashd's approach and eliminating the transient balance overflow. No workaround is available per the vendor advisory - the panic cannot be suppressed through configuration or operational controls, and the restart loop cannot be escaped without a code change. All operators running zebrad ≤4.4.1, including exchanges, light-wallet providers, and mining infrastructure, should treat this upgrade as urgent given that a single malicious block would halt all unpatched nodes simultaneously and recovery requires redeployment of the patched binary. The advisory and patch details are available at https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-w834-cf6p-9m9w.
Same weakness CWE-248 – Uncaught Exception
View allSame technique Buffer Overflow
View allShare
External POC / Exploit Code
Leaving vuln.today