CVE-2026-52733: Zebra state Zebrad Has Persistent On-disk Corruption Vulnerability

MODERATE
Advisory Identifier: GHSA-2gf8-q9rr-jq3h
CVSS 6.5
CWE-672 CWE-459
Published
Advisory Summary

CVE-2026-52733 is a MODERATE (CVSS 6.5) zebrad has persistent on-disk corruption vulnerability (CWE-672: Operation on a Resource after Expiration or Release) affecting Zebra state libraries in the crates.io ecosystem. The issue involves zebrad has persistent on-disk corruption of sapling/orchard subtree roots after chain fork via pop_tip. Remediation is available by upgrading affected packages to version 7.0.0, 4.5.0.

CVE-2026-52733 at a Glance

CVE Identifier CVE-2026-52733
GHSA Identifier GHSA-2gf8-q9rr-jq3h
Severity MODERATE
CVSS v3.1 Base Score 6.5
CWE Classification CWE-672: Operation on a Resource after Expiration or Release
Affected Product Zebra state
Package Ecosystem crates.io
Published Date
Last Updated

Security Impact

CVSS: 6.5

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity High (I:H)
Availability Low (A:L)

How to Fix CVE-2026-52733

To remediate this vulnerability, upgrade all affected Zebra state dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

zebra-state fixed: 7.0.0
Upgrade zebra-state to 7.0.0
zebrad fixed: 4.5.0
Upgrade zebrad to 4.5.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for zebra-state

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-52733, inspect your project dependencies for Zebra state:

inspect dependencies for zebra-state

Analyze the terminal output to locate any version of Zebra state in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 7.0.0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-672: Operation on a Resource after Expiration or Release, where the product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked. In Zebra state, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Am I affected You are affected if: 1. You run `zebrad` up to and including `v4.4.1`. 2. Your node participates in a network where chain forks occur (mainnet, testnet, or any network with multiple miners). All default configurations are affected. The corruption persists across restarts because it is written to RocksDB. ### Summary When `pop_tip` removes the tip block during a chain fork, stale Sapling and Orchard note commitment subtree root data is retained in the in-memory non-finalized state. When the chain subsequently finalizes, this stale data is written to the persistent RocksDB state. The corrupted subtree root history affects `z_getsubtreesbyindex` (used by lightwalletd for wallet synchronization) and could affect future chain verification that depends on correct subtree roots. ### Details The non-finalized state provides two methods for removing blocks: `pop_root` (removes the oldest block during finalization) and `pop_tip` (removes the newest block during a fork revert). `pop_root` correctly cleans up note commitment subtree contributions. `pop_tip` does not: it removes the block but retains the block's subtree root contributions in the in-memory state. When a chain fork occurs and `pop_tip` reverts the old tip, the winning fork's chain is extended. When that chain is later finalized, the stale subtree data from the reverted blocks is included in the RocksDB write batch and persisted to disk. The `pop_root`/`pop_tip` asymmetry is specific to subtree root handling. Other state managed by `pop_tip` (nullifiers, UTXOs, anchors, block hashes) uses different cleanup patterns that are not affected. ### Patches zebra-state 7.0.0 and zebrad 4.5.0. The fix adds subtree root cleanup to `pop_tip` matching the pattern already used by `pop_root`. ### Workarounds There is no configuration-level workaround. Chain forks are natural events on any Proof-of-Work network. Operators can mitigate the downstream impact by periodically verifying subtree root consistency using `z_getsubtreesbyindex` against a known-good reference. ### Impact Persistent corruption of Sapling and Orchard subtree root history in the RocksDB state database. The corruption survives node restarts. Downstream consumers that rely on `z_getsubtreesbyindex` for wallet synchronization (primarily `lightwalletd` and light wallets) receive incorrect subtree roots. This does not directly affect consensus validation of new blocks but can cause wallet synchronization failures or incorrect wallet state. Recovery requires rebuilding the state database from scratch. ### Credit Reported by `@dingledropper` via a private GitHub Security Advisory submission.

CVE-2026-52733 Affected Zebra state Versions

2 component(s)
Fixed Versions:
7.0.04.5.0
Product / Package Ecosystem Affected Versions Fixed Version
zebra-state
crates.io
< 7.0.0
7.0.0
zebrad
crates.io
< 4.5.0
4.5.0

References

Frequently Asked Questions

What is CVE-2026-52733?
CVE-2026-52733 is a security vulnerability in Zebra state involving zebrad has persistent on-disk corruption of Sapling/Orchard subtree roots after chain fork via pop_tip under CWE-672: Operation on a Resource after Expiration or Release.
Which Zebra state versions are affected?
Affected versions include releases prior to 7.0.0, 4.5.0 across affected packages: zebra-state, zebrad.
What version fixes CVE-2026-52733?
Upgrading to 7.0.0, 4.5.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is zebra-state affected?
Yes, zebra-state is affected in releases prior to 7.0.0. Upgrade your dependency to 7.0.0 or later.
Is zebrad affected?
Yes, zebrad is affected in releases prior to 4.5.0. Upgrade your dependency to 4.5.0 or later.
What is the CVSS score of CVE-2026-52733?
CVE-2026-52733 has a CVSS v3.1 base score of 6.5 (MODERATE) with vector string CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L.
What CWE is associated with CVE-2026-52733?
CVE-2026-52733 is classified under CWE-672: Operation on a Resource after Expiration or Release (The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.).
How can I check crates.io dependencies for CVE-2026-52733?
Run the dependency tree command: 'inspect dependencies for zebra-state'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-2gf8-q9rr-jq3h",
  "modified" : "2026-07-02T20:11:36Z",
  "published" : "2026-07-02T20:11:36Z",
  "aliases" : [ "CVE-2026-52733" ],
  "summary" : "zebrad has persistent on-disk corruption of Sapling/Orchard subtree roots after chain fork via pop_tip",
  "details" : "### Am I affected\n\nYou are affected if:\n\n1. You run `zebrad` up to and including `v4.4.1`.\n2. Your node participates in a network where chain forks occur (mainnet, testnet, or any network with multiple miners).\n\nAll default configurations are affected. The corruption persists across restarts because it is written to RocksDB.\n\n### Summary\n\nWhen `pop_tip` removes the tip block during a chain fork, stale Sapling and Orchard note commitment subtree root data is retained in the in-memory non-finalized state. When the chain subsequently finalizes, this stale data is written to the persistent RocksDB state. The corrupted subtree root history affects `z_getsubtreesbyindex` (used by lightwalletd for wallet synchronization) and could affect future chain verification that depends on correct subtree roots.\n\n### Details\n\nThe non-finalized state provides two methods for removing blocks: `pop_root` (removes the oldest block during finalization) and `pop_tip` (removes the newest block during a fork revert). `pop_root` correctly cleans up note commitment subtree contributions. `pop_tip` does not: it removes the block but retains the block's subtree root contributions in the in-memory state.\n\nWhen a chain fork occurs and `pop_tip` reverts the old tip, the winning fork's chain is extended. When that chain is later finalized, the stale subtree data from the reverted blocks is included in the RocksDB write batch and persisted to disk.\n\nThe `pop_root`/`pop_tip` asymmetry is specific to subtree root handling. Other state managed by `pop_tip` (nullifiers, UTXOs, anchors, block hashes) uses different cleanup patterns that are not affected.\n\n### Patches\n\nzebra-state 7.0.0 and zebrad 4.5.0.\n\nThe fix adds subtree root cleanup to `pop_tip` matching the pattern already used by `pop_root`.\n\n### Workarounds\n\nThere is no configuration-level workaround. Chain forks are natural events on any Proof-of-Work network. Operators can mitigate the downstream impact by periodically verifying subtree root consistency using `z_getsubtreesbyindex` against a known-good reference.\n\n### Impact\n\nPersistent corruption of Sapling and Orchard subtree root history in the RocksDB state database. The corruption survives node restarts. Downstream consumers that rely on `z_getsubtreesbyindex` for wallet synchronization (primarily `lightwalletd` and light wallets) receive incorrect subtree roots. This does not directly affect consensus validation of new blocks but can cause wallet synchronization failures or incorrect wallet state. Recovery requires rebuilding the state database from scratch.\n\n### Credit\n\nReported by `@dingledropper` via a private GitHub Security Advisory submission.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "zebra-state"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "7.0.0"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 6.0.0"
    }
  }, {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "zebrad"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "4.5.0"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 4.4.1"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-2gf8-q9rr-jq3h"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/ZcashFoundation/zebra"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-459", "CWE-672" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-07-02T20:11:36Z",
    "nvd_published_at" : null
  }
}