CVE-2026-52733 in Zebra
Summary
by MITRE • 08/18/2026
ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, a natural or attacker-influenced chain fork can leave stale Sapling and Orchard note-commitment subtree roots in Zebra state. In zebra-state/src/service/non_finalized_state/chain.rs, Chain::pop_tip removed a reverted tip block but did not remove subtree entries whose end_height belonged to that block, unlike the cleanup performed by pop_root. When the winning fork later finalized, the abandoned branch's stale subtree data could be written to RocksDB and survive node restarts. The corrupted history can cause z_getsubtreesbyindex consumers such as lightwalletd and light wallets to receive incorrect subtree roots, producing wallet synchronization failures or incorrect wallet state and requiring a full state rebuild for recovery. This issue is fixed in version 4.5.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in Zebra versions prior to 4.5.0 represents a critical data integrity flaw within the node's state management logic, specifically affecting the handling of Sapling and Orchard note-commitment subtrees during chain reorganizations. As a Rust-based implementation of a Zcash full node, Zebra is responsible for maintaining an accurate representation of the blockchain history, including the complex tree structures required by shielded transactions. The core technical flaw resides in the Chain::pop_tip function located within zebra-state/src/service/non_finalized_state/chain.rs. When a chain fork occurs and a previously accepted tip block is reverted due to a longer or higher-priority chain being discovered, this function correctly removes the block itself from memory but fails to perform equivalent cleanup for associated subtree entries. Specifically, it neglects to remove note-commitment subtree roots whose end_height corresponds to the abandoned block. This inconsistency contrasts sharply with the behavior of pop_root, which properly handles such cleanup operations during deep reorganizations starting from the genesis block.
The operational impact of this oversight is severe and persistent due to the underlying storage mechanism used by Zebra, namely RocksDB. When a previously forked chain eventually becomes the canonical history through finalization, the stale subtree data associated with the abandoned branch remains in the database because it was never properly purged during the initial reorganization phase. Consequently, this corrupted historical state is written to persistent storage and survives node restarts. This leads to a divergence between the actual blockchain state and the stored note-commitment tree roots. For consumers of this state data, such as lightwalletd and various Zcash light wallets that rely on z_getsubtreesbyindex RPC calls, the result is catastrophic synchronization failure or incorrect wallet states. Users may find their balances unresponsive, transactions failing to confirm correctly, or historical transaction data appearing inconsistent with reality. The only viable recovery method for affected nodes is a complete state rebuild from scratch, which imposes significant computational and time costs on node operators and disrupts service availability for dependent applications.
From a classification perspective, this vulnerability aligns closely with CWE-20: Improper Input Validation, as the system fails to correctly validate and maintain internal consistency during chain reorganization events. It also relates to CWE-835: Loop with Unreachable Exit Condition in terms of state cleanup logic where certain code paths are bypassed under specific fork conditions. In the context of MITRE ATT&CK, while this is not an exploit by a malicious actor but rather a consequence of natural or attacker-influenced chain forks, it impacts Availability and Integrity within the CIA triad. The failure to maintain accurate state data undermines trust in the node's output, which is critical for decentralized applications relying on Zebra as a backend service provider.
Mitigation strategies primarily involve upgrading to version 4.5.0 or later of Zebra, where this logic error has been corrected to ensure that subtree entries are properly removed during tip reversion just as they are during root reversion. For operators currently running vulnerable versions who have already experienced state corruption, the recommended course of action is to perform a full resync of the blockchain data from genesis or a trusted checkpoint to purge the stale note-commitment roots. Implementing automated monitoring for chain reorganizations and verifying subtree consistency after such events can help detect this issue early in environments where upgrading may be delayed. Ensuring that state management logic treats all forms of block removal with equal rigor regarding associated metadata is essential for maintaining the integrity of shielded transaction histories in Zcash-compatible systems.