The vulnerability in Zebra's non-finalized state handling occurs because the transaction-location index (`tx_loc_by_hash`) is updated before the duplicate shielded-nullifier check. When a child block repeats a shielded transaction from its non-finalized parent, an assertion designed to enforce transaction uniqueness triggers a panic and aborts the node process instead of cleanly rejecting the block. This is due to the ordering of index updates and validation checks in `Chain::push`. The block transaction verifier does not perform the best-chain nullifier query for block transactions in non-finalized state, allowing this condition to cause a process abort. Two attack models exist: one where an attacker mines two consecutive blocks with a repeated shielded transaction, and another where an attacker broadcasts a shielded transaction and mines the immediate child block repeating it. Both cause a denial-of-service by crashing the node process.

A malicious block producer can cause targeted Zebra nodes to crash and abort their process, resulting in denial-of-service and requiring node restarts. This can be exploited repeatedly to keep nodes offline for extended periods. The issue affects node liveness but does not cause consensus divergence, as other implementations like zcashd reject the invalid block cleanly. The attack requires the child block to repeat a shielded-only V5 transaction from a non-finalized parent block. The frequency of attack opportunities depends on the attacker's hashrate, with higher hashrates enabling more frequent attacks.

An official fix is available in zebra-state 7.0.0 and zebrad 4.5.0, which replaces the assertion with an error return for duplicate transactions, preventing process aborts. There is no configuration-level workaround. Users should upgrade to these fixed versions to prevent denial-of-service crashes caused by repeated shielded transactions in non-finalized state.