Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Am I affected You are affected if: 1. You run zebrad up to and including v4.4.1. 2. Your node participates in a network where chain forks occur (mainnet, testnet, or any network with multiple miners). All default configurations are affected. The corruption persists across restarts because it is written to RocksDB. Summary When poptip removes the tip block during a chain fork, stale Sapling and Orchard note commitment subtree root data is retained in the in-memory non-finalized state. When the chain subsequently finalizes, this stale data is written to the persistent RocksDB state. The corrupted subtree root history affects zgetsubtreesbyindex (used by lightwalletd for wallet synchronization) and could affect future chain verification that depends on correct subtree roots. Details The non-finalized state provides two methods for removing blocks: poproot (removes the oldest block during finalization) and poptip (removes the newest block during a fork revert). poproot correctly cleans…
Recommended action: Upgrade to 7.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Am I affected You are affected if: 1. You run zebrad up to and including v4.4.1. 2. Your node processes blocks past the checkpoint height (non-finalized state is active). 3. The network has NU5 or later activated. All default configurations are affected. Summary Chain::push in the non-finalized state updates the transaction-location index (txlocbyhash) before it runs the duplicate shielded-nullifier guard. When an invalid child block repeats a shielded transaction from its non-finalized parent, the asserteq!(priorpair, None, "transactions must be unique within a single chain") fires before the contextual validation that would cleanly reject the duplicate. Under Zebra's panic = "abort" release profile, this terminates the entire node process. The block should be rejected with a duplicate-nullifier contextual validation error. Instead, the ordering of index updates within Chain::push causes the process to abort. Details In zebra-state/src/service/nonfinalizedstate/chain.rs:1608-1628,…
Recommended action: Upgrade to 7.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 MAXMONEY, 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/finalizedstate/zebradb/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…
Recommended action: Upgrade to 7.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Am I affected You are affected if: 1. You run any version of zebrad up to and including v4.4.1. 2. Your node accepts inbound P2P connections (network.listenaddr is set, which is the default). 3. Your node processes blocks past the checkpoint height (non-finalized state is active). All default configurations are affected. Summary Zebra records a block hash in nonfinalizedblockwritesenthashes when the block is sent to the write task, before contextual validation completes. If validation fails, the hash is not removed. A remote unauthenticated peer can deliver a poisoned block body that shares a header hash with a later valid canonical block. The poisoned body is rejected, but the hash remains cached. When the valid canonical block arrives, Zebra treats it as a duplicate and rejects it. The node cannot advance past that height until restart or a reorg event. Details ZIP-244 defines txidv5 without binding transparent input scriptSig, which lives in authdigest and is committed…
Recommended action: Upgrade to 7.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.