Skip to content

Zebra has block suppression via NU5 same-header body poisoning of sent-hash cache

High severity GitHub Reviewed Published May 29, 2026 in ZcashFoundation/zebra • Updated Jul 2, 2026

Package

cargo zebra-state (Rust)

Affected versions

<= 6.0.0

Patched versions

7.0.0
cargo zebrad (Rust)
<= 4.4.1
4.5.0

Description

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 canonical block arrives (from honest peers or RPC), queue_and_commit_to_non_finalized_state sees the hash in the cache and returns KnownBlock::WriteChannel duplicate.
  9. The node is stuck at height N-1.

A secondary variant exists where chain pruning (via MAX_NON_FINALIZED_CHAIN_FORKS) removes a chain from chain_set but leaves its block hashes in non_finalized_block_write_sent_hashes, producing the same lockout for children of the pruned fork.

Patches

Patched in Zebra 4.4.2. The fix removes stale entries from non_finalized_block_write_sent_hashes on every failed non-finalized write path.

Workarounds

There is no complete configuration-level workaround. Reducing the node's inbound peer count (network.peerset_initial_target_size) narrows the attack surface but does not eliminate it. Restarting the node clears the in-memory cache and allows the valid block to be re-fetched.

Impact

A remote unauthenticated P2P peer can permanently stall a targeted Zebra node at a specific block height. The node diverges from the network tip; downstream consumers (lightwalletd, wallets, explorers, mining infrastructure) relying on the node see a stalled chain. The attack requires winning a propagation race: delivering the poisoned block body before honest peers deliver the canonical block. A well-positioned attacker (low-latency connection to the target, observation of new blocks from other peers) can reliably win this race. In sustained form, the attacker repeats for each new block, keeping the target permanently behind.

Recovery requires restarting the node (which clears the in-memory sent-hash cache) or waiting for a reorg at the affected height (rare on the canonical chain).

Credit

Reported independently by @ipwning (primary, with ZIP-244 malleability analysis and zcashd cross-reference) and @x15-eth (first reporter, with E2E reproduction and control experiment).

References

@mpguerra mpguerra published to ZcashFoundation/zebra May 29, 2026
Published to the GitHub Advisory Database Jul 2, 2026
Reviewed Jul 2, 2026
Last updated Jul 2, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements None
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality None
Integrity High
Availability None
Subsequent System Impact Metrics
Confidentiality None
Integrity None
Availability None

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(37th percentile)

Weaknesses

Incomplete Cleanup

The product does not properly clean up and remove temporary or supporting resources after they have been used. Learn more on MITRE.

CVE ID

CVE-2026-52736

GHSA ID

GHSA-4m69-67m6-prqp

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.