The flaw is in Zebra’s handling of the sighash type. An invalid hash type is not reported as an error, causing the code to continue and leaving the sighash buffer unchanged. If the buffer already holds a valid sighash from a prior signature validation, a subsequent transaction can reuse that stale value even though the new hash type is invalid. The transaction is then incorrectly accepted on a Zebra node while a compliant node, such as zcashd, would reject it, creating a split in the consensus chain. This undermines the integrity of the network by enabling two separate blockchains to coexist.

ZcashFoundation’s Zebra node in versions of zebrad earlier than 4.4.0 and zebra-script earlier than 6.0.0 is affected. Anyone running a full Zebra node or masternode before these version thresholds must be aware of the risk.

With a CVSS score of 9.3 the vulnerability is classified as critical. The EPSS score is unavailable, and the issue is not listed in the CISA KEV catalog. The attack vector requires only the transmission of a specially crafted transaction over the network; no privileged access is needed. If executed, the inconsistency can produce a forking event that compromises the network’s availability and potentially leads to double spending until the patch is applied.