Zebra records block hashes in a cache before contextual validation completes. If a remote unauthenticated peer sends a poisoned block body with a header hash identical to a valid canonical block but with an invalid body, the hash remains cached after rejection. When the valid block arrives, Zebra treats it as a duplicate and rejects it, causing the node to stall at that block height. This is due to ZIP-244 allowing two blocks with identical header hashes but different transaction bodies by mutating the coinbase scriptSig. The attack requires the node to accept inbound P2P connections and process blocks past checkpoint height. The vulnerability is fixed in Zebra 4.4.2 by removing stale cache entries on validation failure.

A remote unauthenticated P2P peer can permanently stall a Zebra node at a specific block height by exploiting the caching of rejected block hashes. This causes the node to diverge from the network tip, affecting downstream services relying on the node such as wallets and explorers. The attack requires winning a propagation race to deliver the poisoned block body before the canonical block. Sustained attacks can keep the node permanently behind. Recovery requires node restart or a rare chain reorganization.

This vulnerability is patched in Zebra version 4.4.2. Users should upgrade to 4.4.2 or later to resolve the issue. There is no complete configuration-level workaround; reducing inbound peer count may reduce attack surface but does not eliminate the risk. Restarting the node clears the in-memory cache and allows recovery if the node is stalled.