{"id":"CVE-2026-52738","aliases":[],"url":"https://o3.security/vulnerability/CVE-2026-52738","summary":"Zebra: Finalized address balance credit-first overflow on consensus-valid blocks","details":"### Am I affected\n\nYou are affected if:\n\n1. You run `zebrad` up to and including `v4.4.1`.\n2. Your node processes blocks on any Zcash network.\n\n### Summary\n\nThe 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.\n\nBecause 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.\n\n### Details\n\nThe 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.\n\nThe 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.\n\nAn 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.\n\n### Patches\n\nPatched 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.\n\n### Workarounds\n\nNo workaround is available. Upgrade to Zebra 4.4.2.\n\n### Impact\n\nA 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.\n\n### Credit\n\nReported by `@sangsoo-osec`.","published":"2026-07-02T19:44:54Z","modified":"2026-07-02T20:00:08.013563287Z","cvss":null,"epss":null,"cisaKev":null,"exploitsKnown":null,"affectedPackages":[{"ecosystem":"crates.io","name":"zebra-state","fixedVersion":"7.0.0"},{"ecosystem":"crates.io","name":"zebrad","fixedVersion":"4.5.0"}],"fix":null,"references":[{"type":"WEB","url":"https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-w834-cf6p-9m9w"},{"type":"PACKAGE","url":"https://github.com/ZcashFoundation/zebra"}],"provenance":{"sources":["OSV.dev","FIRST.org (EPSS)"],"lastVerified":"2026-07-02T20:00:08.013563287Z"}}