GHSA-2gf8-q9rr-jq3h
MEDIUMGHSA-2gf8-q9rr-jq3h is a medium-severity (CVSS 6.5) CWE-459 vulnerability in zebra-state. O3 Security confirms whether GHSA-2gf8-q9rr-jq3h is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
zebrad has persistent on-disk corruption of Sapling/Orchard subtree roots after chain fork via pop_tip
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-2gf8-q9rr-jq3h plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 370,894 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
zebra-state🦀zebradReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
Am I affected
You are affected if:
- You run
zebradup to and includingv4.4.1. - 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | zebra-state | all versions | 7.0.0 |
| 🦀crates.io | zebrad | all versions | 4.5.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for zebra-state. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update zebra-state to 7.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2gf8-q9rr-jq3h is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-2gf8-q9rr-jq3h is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-2gf8-q9rr-jq3h. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-2gf8-q9rr-jq3h in your dependencies?
O3 detects GHSA-2gf8-q9rr-jq3h across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.