The finalized transparent address balance writer in Zebra state (up to v4.4.1) processes all newly-created outputs (credits) before spent outputs (debits) within the same block. When a consensus-valid block contains a long chain of same-address transparent self-spends, the intermediate balance during the credit pass can exceed the maximum money supply (MAX_MONEY), triggering a panic due to an overflow check. This panic aborts the node process, and on restart, the node reprocesses the same block, causing a persistent halt. An attacker with mining capability and a capital of roughly 1,100–2,100 ZEC can exploit this to halt all Zebra nodes. The issue is patched in Zebra 4.4.2 by processing credits and debits together per transaction, aligning with zcashd's approach. No workaround is available other than upgrading.

A single consensus-valid block constructed by an attacker can permanently halt all Zebra nodes running vulnerable versions, causing a persistent chain halt that survives node restarts. This results in service disruption for downstream consumers such as light wallets, exchanges, and mining infrastructure. The attacker recovers their capital since the exploit involves self-spends, so the net cost is the mining effort only. There is no indication of data corruption or consensus failure beyond the node halt.

Upgrade Zebra state to version 4.4.2 or later, which contains the official fix. The patch changes the processing order of credits and debits to prevent intermediate balance overflow. No workaround is available; running vulnerable versions will result in persistent node halts upon encountering the crafted block.