CVE-2026-52736

## Description ### 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.listen_addr` 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 `non_finalized_block_write_sent_hashes` 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 `txid_v5` without binding transparent input `scriptSig`, which lives in `auth_digest` and is committed to by `hashBlockCommitments` in the block header. Because `merkle_root` is computed over txids (not auth digests), and the block hash is computed over the header, an attacker can construct two blocks with identical header hashes but different transaction bodies by mutating the coinbase scriptSig. The attack flow over P2P: 1. Attacker observes a new block header (from any peer). 2. Attacker constructs a poisoned body by flipping a byte of the coinbase scriptSig extra-data section. The block hash is unchanged. 3. Attacker advertises the block hash via `inv` to the target node. 4. Target requests the block via `getdata`; attacker serves the poisoned body. 5. Zebra adds the hash to `non_finalized_block_write_sent_hashes` before validation. 6. The write task rejects the body at `block_commitment_is_valid_for_chain_history` (auth_data_root mismatch). 7. The hash is not removed from `non_finalized_block_write_sent_hashes`. 8. When the valid canoni