Vulnerability-Lookup

CVE-2026-52736 (GCVE-0-2026-52736)

Vulnerability from cvelistv5 – Published: 2026-08-18 19:26 – Updated: 2026-08-18 19:38

Title

ZEBRA: Block suppression via NU5 same-header body poisoning of sent-hash cache

Summary

ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, a remote unauthenticated P2P peer can stall a Zebra node by racing an invalid block body against the valid canonical body for the same block header hash. ZIP-244 permits the attacker to mutate coinbase scriptSig authentication data while retaining the transaction identifiers, merkle root, and block header hash, so the poisoned body fails later commitment validation but shares the canonical hash. In zebra-state/src/service.rs, queue_and_commit_to_non_finalized_state recorded the hash in non_finalized_block_write_sent_hashes before contextual validation completed and did not remove it when the write task rejected the body. When the honest body later arrived, the cached hash caused KnownBlock::WriteChannel duplicate handling to suppress it, leaving the node stuck one height behind until restart or reorganization. This issue is fixed in version 4.5.0.

Severity

8.7 (High)


                        
                          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

SSVC

Exploitation: none Automatable: yes Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-08-18 19:38 UTC

CWE

CWE-459 - Incomplete Cleanup

Assigner

GitHub_M mitre root

References

3 references

URL	Tags
https://github.com/ZcashFoundation/zebra/security…	x_refsource_CONFIRM
https://github.com/ZcashFoundation/zebra/commit/1…	x_refsource_MISC
https://github.com/ZcashFoundation/zebra/releases…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version	CPE status
ZcashFoundation	zebra	Affected: < 4.5.0	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-52736",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-18T19:38:19.383112Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-18T19:38:44.395Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "zebra",
          "vendor": "ZcashFoundation",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 4.5.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, a remote unauthenticated P2P peer can stall a Zebra node by racing an invalid block body against the valid canonical body for the same block header hash. ZIP-244 permits the attacker to mutate coinbase scriptSig authentication data while retaining the transaction identifiers, merkle root, and block header hash, so the poisoned body fails later commitment validation but shares the canonical hash. In zebra-state/src/service.rs, queue_and_commit_to_non_finalized_state recorded the hash in non_finalized_block_write_sent_hashes before contextual validation completed and did not remove it when the write task rejected the body. When the honest body later arrived, the cached hash caused KnownBlock::WriteChannel duplicate handling to suppress it, leaving the node stuck one height behind until restart or reorganization. This issue is fixed in version 4.5.0."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 8.7,
            "baseSeverity": "HIGH",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "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",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "HIGH"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-459",
              "description": "CWE-459: Incomplete Cleanup",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-18T19:26:40.575Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-4m69-67m6-prqp",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-4m69-67m6-prqp"
        },
        {
          "name": "https://github.com/ZcashFoundation/zebra/commit/1440b43ca7df59aca948090d45117557b217a6cd",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/ZcashFoundation/zebra/commit/1440b43ca7df59aca948090d45117557b217a6cd"
        },
        {
          "name": "https://github.com/ZcashFoundation/zebra/releases/tag/v4.5.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/ZcashFoundation/zebra/releases/tag/v4.5.0"
        }
      ],
      "source": {
        "advisory": "GHSA-4m69-67m6-prqp",
        "discovery": "UNKNOWN"
      },
      "title": "ZEBRA: Block suppression via NU5 same-header body poisoning of sent-hash cache"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-52736",
    "datePublished": "2026-08-18T19:26:40.575Z",
    "dateReserved": "2026-06-08T14:00:43.572Z",
    "dateUpdated": "2026-08-18T19:38:44.395Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-52736\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2026-08-18T20:17:17.400\",\"lastModified\":\"2026-08-18T20:17:17.400\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, a remote unauthenticated P2P peer can stall a Zebra node by racing an invalid block body against the valid canonical body for the same block header hash. ZIP-244 permits the attacker to mutate coinbase scriptSig authentication data while retaining the transaction identifiers, merkle root, and block header hash, so the poisoned body fails later commitment validation but shares the canonical hash. In zebra-state/src/service.rs, queue_and_commit_to_non_finalized_state recorded the hash in non_finalized_block_write_sent_hashes before contextual validation completed and did not remove it when the write task rejected the body. When the honest body later arrived, the cached hash caused KnownBlock::WriteChannel duplicate handling to suppress it, leaving the node stuck one height behind until restart or reorganization. This issue is fixed in version 4.5.0.\"}],\"affected\":[{\"source\":\"security-advisories@github.com\",\"affectedData\":[{\"vendor\":\"ZcashFoundation\",\"product\":\"zebra\",\"versions\":[{\"version\":\"\u003c 4.5.0\",\"status\":\"affected\"}]}]}],\"metrics\":{\"cvssMetricV40\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"4.0\",\"vectorString\":\"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X\",\"baseScore\":8.7,\"baseSeverity\":\"HIGH\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"attackRequirements\":\"NONE\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"vulnConfidentialityImpact\":\"NONE\",\"vulnIntegrityImpact\":\"HIGH\",\"vulnAvailabilityImpact\":\"NONE\",\"subConfidentialityImpact\":\"NONE\",\"subIntegrityImpact\":\"NONE\",\"subAvailabilityImpact\":\"NONE\",\"exploitMaturity\":\"NOT_DEFINED\",\"confidentialityRequirement\":\"NOT_DEFINED\",\"integrityRequirement\":\"NOT_DEFINED\",\"availabilityRequirement\":\"NOT_DEFINED\",\"modifiedAttackVector\":\"NOT_DEFINED\",\"modifiedAttackComplexity\":\"NOT_DEFINED\",\"modifiedAttackRequirements\":\"NOT_DEFINED\",\"modifiedPrivilegesRequired\":\"NOT_DEFINED\",\"modifiedUserInteraction\":\"NOT_DEFINED\",\"modifiedVulnConfidentialityImpact\":\"NOT_DEFINED\",\"modifiedVulnIntegrityImpact\":\"NOT_DEFINED\",\"modifiedVulnAvailabilityImpact\":\"NOT_DEFINED\",\"modifiedSubConfidentialityImpact\":\"NOT_DEFINED\",\"modifiedSubIntegrityImpact\":\"NOT_DEFINED\",\"modifiedSubAvailabilityImpact\":\"NOT_DEFINED\",\"Safety\":\"NOT_DEFINED\",\"Automatable\":\"NOT_DEFINED\",\"Recovery\":\"NOT_DEFINED\",\"valueDensity\":\"NOT_DEFINED\",\"vulnerabilityResponseEffort\":\"NOT_DEFINED\",\"providerUrgency\":\"NOT_DEFINED\"}}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2026-08-18T19:38:19.383112Z\",\"id\":\"CVE-2026-52736\",\"options\":[{\"exploitation\":\"none\"},{\"automatable\":\"yes\"},{\"technicalImpact\":\"partial\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-459\"}]}],\"references\":[{\"url\":\"https://github.com/ZcashFoundation/zebra/commit/1440b43ca7df59aca948090d45117557b217a6cd\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/ZcashFoundation/zebra/releases/tag/v4.5.0\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-4m69-67m6-prqp\",\"source\":\"security-advisories@github.com\"}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-52736\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"yes\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-08-18T19:38:19.383112Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-08-18T19:38:30.293Z\"}}], \"cna\": {\"title\": \"ZEBRA: Block suppression via NU5 same-header body poisoning of sent-hash cache\", \"source\": {\"advisory\": \"GHSA-4m69-67m6-prqp\", \"discovery\": \"UNKNOWN\"}, \"metrics\": [{\"cvssV4_0\": {\"version\": \"4.0\", \"baseScore\": 8.7, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"HIGH\", \"vectorString\": \"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\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"attackRequirements\": \"NONE\", \"privilegesRequired\": \"NONE\", \"subIntegrityImpact\": \"NONE\", \"vulnIntegrityImpact\": \"HIGH\", \"subAvailabilityImpact\": \"NONE\", \"vulnAvailabilityImpact\": \"NONE\", \"subConfidentialityImpact\": \"NONE\", \"vulnConfidentialityImpact\": \"NONE\"}}], \"affected\": [{\"vendor\": \"ZcashFoundation\", \"product\": \"zebra\", \"versions\": [{\"status\": \"affected\", \"version\": \"\u003c 4.5.0\"}]}], \"references\": [{\"url\": \"https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-4m69-67m6-prqp\", \"name\": \"https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-4m69-67m6-prqp\", \"tags\": [\"x_refsource_CONFIRM\"]}, {\"url\": \"https://github.com/ZcashFoundation/zebra/commit/1440b43ca7df59aca948090d45117557b217a6cd\", \"name\": \"https://github.com/ZcashFoundation/zebra/commit/1440b43ca7df59aca948090d45117557b217a6cd\", \"tags\": [\"x_refsource_MISC\"]}, {\"url\": \"https://github.com/ZcashFoundation/zebra/releases/tag/v4.5.0\", \"name\": \"https://github.com/ZcashFoundation/zebra/releases/tag/v4.5.0\", \"tags\": [\"x_refsource_MISC\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, a remote unauthenticated P2P peer can stall a Zebra node by racing an invalid block body against the valid canonical body for the same block header hash. ZIP-244 permits the attacker to mutate coinbase scriptSig authentication data while retaining the transaction identifiers, merkle root, and block header hash, so the poisoned body fails later commitment validation but shares the canonical hash. In zebra-state/src/service.rs, queue_and_commit_to_non_finalized_state recorded the hash in non_finalized_block_write_sent_hashes before contextual validation completed and did not remove it when the write task rejected the body. When the honest body later arrived, the cached hash caused KnownBlock::WriteChannel duplicate handling to suppress it, leaving the node stuck one height behind until restart or reorganization. This issue is fixed in version 4.5.0.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-459\", \"description\": \"CWE-459: Incomplete Cleanup\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2026-08-18T19:26:40.575Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-52736\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-08-18T19:38:44.395Z\", \"dateReserved\": \"2026-06-08T14:00:43.572Z\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"datePublished\": \"2026-08-18T19:26:40.575Z\", \"assignerShortName\": \"GitHub_M\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

FKIE_CVE-2026-52736

Vulnerability from fkie_nvd - Published: 2026-08-18 20:17 - Updated: 2026-08-18 20:17

Severity

8.7 (High) - 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

Summary

References

	URL	Tags
	security-advisories@github.com	https://github.com/ZcashFoundation/zebra/commit/1440b43ca7df59aca948090d45117557b217a6cd
	security-advisories@github.com	https://github.com/ZcashFoundation/zebra/releases/tag/v4.5.0
	security-advisories@github.com	https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-4m69-67m6-prqp

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "product": "zebra",
          "vendor": "ZcashFoundation",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 4.5.0"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, a remote unauthenticated P2P peer can stall a Zebra node by racing an invalid block body against the valid canonical body for the same block header hash. ZIP-244 permits the attacker to mutate coinbase scriptSig authentication data while retaining the transaction identifiers, merkle root, and block header hash, so the poisoned body fails later commitment validation but shares the canonical hash. In zebra-state/src/service.rs, queue_and_commit_to_non_finalized_state recorded the hash in non_finalized_block_write_sent_hashes before contextual validation completed and did not remove it when the write task rejected the body. When the honest body later arrived, the cached hash caused KnownBlock::WriteChannel duplicate handling to suppress it, leaving the node stuck one height behind until restart or reorganization. This issue is fixed in version 4.5.0."
    }
  ],
  "id": "CVE-2026-52736",
  "lastModified": "2026-08-18T20:17:17.400",
  "metrics": {
    "cvssMetricV40": [
      {
        "cvssData": {
          "Automatable": "NOT_DEFINED",
          "Recovery": "NOT_DEFINED",
          "Safety": "NOT_DEFINED",
          "attackComplexity": "LOW",
          "attackRequirements": "NONE",
          "attackVector": "NETWORK",
          "availabilityRequirement": "NOT_DEFINED",
          "baseScore": 8.7,
          "baseSeverity": "HIGH",
          "confidentialityRequirement": "NOT_DEFINED",
          "exploitMaturity": "NOT_DEFINED",
          "integrityRequirement": "NOT_DEFINED",
          "modifiedAttackComplexity": "NOT_DEFINED",
          "modifiedAttackRequirements": "NOT_DEFINED",
          "modifiedAttackVector": "NOT_DEFINED",
          "modifiedPrivilegesRequired": "NOT_DEFINED",
          "modifiedSubAvailabilityImpact": "NOT_DEFINED",
          "modifiedSubConfidentialityImpact": "NOT_DEFINED",
          "modifiedSubIntegrityImpact": "NOT_DEFINED",
          "modifiedUserInteraction": "NOT_DEFINED",
          "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
          "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
          "modifiedVulnIntegrityImpact": "NOT_DEFINED",
          "privilegesRequired": "NONE",
          "providerUrgency": "NOT_DEFINED",
          "subAvailabilityImpact": "NONE",
          "subConfidentialityImpact": "NONE",
          "subIntegrityImpact": "NONE",
          "userInteraction": "NONE",
          "valueDensity": "NOT_DEFINED",
          "vectorString": "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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
          "version": "4.0",
          "vulnAvailabilityImpact": "NONE",
          "vulnConfidentialityImpact": "NONE",
          "vulnIntegrityImpact": "HIGH",
          "vulnerabilityResponseEffort": "NOT_DEFINED"
        },
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-52736",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "yes"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-08-18T19:38:19.383112Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-08-18T20:17:17.400",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/ZcashFoundation/zebra/commit/1440b43ca7df59aca948090d45117557b217a6cd"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/ZcashFoundation/zebra/releases/tag/v4.5.0"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-4m69-67m6-prqp"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Received",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-459"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Primary"
    }
  ]
}

GHSA-4M69-67M6-PRQP

Vulnerability from github – Published: 2026-07-02 19:43 – Updated: 2026-07-02 19:43

Summary

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

Details

Description

Am I affected

You are affected if:

You run any version of zebrad up to and including v4.4.1.
Your node accepts inbound P2P connections (network.listen_addr is set, which is the default).
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:

Attacker observes a new block header (from any peer).
Attacker constructs a poisoned body by flipping a byte of the coinbase scriptSig extra-data section. The block hash is unchanged.
Attacker advertises the block hash via inv to the target node.
Target requests the block via getdata; attacker serves the poisoned body.
Zebra adds the hash to non_finalized_block_write_sent_hashes before validation.
The write task rejects the body at block_commitment_is_valid_for_chain_history (auth_data_root mismatch).
The hash is not removed from non_finalized_block_write_sent_hashes.
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.
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).

Severity

8.7 (High)


                  
                    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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.0.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "zebra-state"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.4.1"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "zebrad"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52736"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-459"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T19:43:08Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Description\n\n### Am I affected\n\nYou are affected if:\n\n1. You run any version of `zebrad` up to and including `v4.4.1`.\n2. Your node accepts inbound P2P connections (`network.listen_addr` is set, which is the default).\n3. Your node processes blocks past the checkpoint height (non-finalized state is active).\n\nAll default configurations are affected.\n\n### Summary\n\nZebra 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.\n\n### Details\n\nZIP-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.\n\nThe attack flow over P2P:\n\n1. Attacker observes a new block header (from any peer).\n2. Attacker constructs a poisoned body by flipping a byte of the coinbase scriptSig extra-data section. The block hash is unchanged.\n3. Attacker advertises the block hash via `inv` to the target node.\n4. Target requests the block via `getdata`; attacker serves the poisoned body.\n5. Zebra adds the hash to `non_finalized_block_write_sent_hashes` before validation.\n6. The write task rejects the body at `block_commitment_is_valid_for_chain_history` (auth_data_root mismatch).\n7. The hash is not removed from `non_finalized_block_write_sent_hashes`.\n8. 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.\n9. The node is stuck at height N-1.\n\nA 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.\n\n### Patches\n\nPatched in Zebra 4.4.2. The fix removes stale entries from `non_finalized_block_write_sent_hashes` on every failed non-finalized write path.\n\n### Workarounds\n\nThere is no complete configuration-level workaround. Reducing the node\u0027s 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.\n\n### Impact\n\nA 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.\n\nRecovery 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).\n\n### Credit\n\nReported independently by `@ipwning` (primary, with ZIP-244 malleability analysis and zcashd cross-reference) and `@x15-eth` (first reporter, with E2E reproduction and control experiment).",
  "id": "GHSA-4m69-67m6-prqp",
  "modified": "2026-07-02T19:43:08Z",
  "published": "2026-07-02T19:43:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-4m69-67m6-prqp"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ZcashFoundation/zebra"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/blob/d4cd662c716382f6397d2a730148025a1ca79fec/zebra-state/src/service.rs#L659-L714"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/blob/d4cd662c716382f6397d2a730148025a1ca79fec/zebra-state/src/service.rs#L797-L802"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Zebra has block suppression via NU5 same-header body poisoning of sent-hash cache"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.

Action not permitted

CVE-2026-52736 (GCVE-0-2026-52736)

FKIE_CVE-2026-52736

GHSA-4M69-67M6-PRQP

Description

Am I affected

Summary

Details

Patches

Workarounds

Impact

Credit

Tags

Sightings

Nomenclature