### Am I affected You are affected if: 1. You run `zebrad` up to and including `v4.4.1`. 2. 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`.
### Am I affected You are affected if: 1. You run `zebrad` up to and including `v4.4.1`. 2. 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`.
Update zebrad to 4.5.0; zebra-state to 7.0.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanZebra: Finalized address balance credit-first overflow on consensus-valid blocks affects zebrad (rust), zebra-state (rust). Severity is medium. ### Am I affected You are affected if: 1. You run `zebrad` up to and including `v4.4.1`. 2. 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`.
AI coding agents often install or upgrade packages automatically in rust. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| zebradrust | <=4.4.1 | 4.5.0 |
| zebra-staterust | <=6.0.0 | 7.0.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate zebrad to 4.5.0; zebra-state to 7.0.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanZebra: Finalized address balance credit-first overflow on consensus-valid blocks affects zebrad (rust), zebra-state (rust). Severity is medium. ### Am I affected You are affected if: 1. You run `zebrad` up to and including `v4.4.1`. 2. 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`.
AI coding agents often install or upgrade packages automatically in rust. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| zebradrust | <=4.4.1 | 4.5.0 |
| zebra-staterust | <=6.0.0 | 7.0.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard