The vulnerability in zebrad (Zebra script) arises from its P2SH sigop counter using a pure-Rust code path that prematurely terminates counting upon encountering disabled opcodes, returning a partial sigop count of zero for subsequent sigops. In contrast, the reference implementation zcashd counts through disabled opcodes during static sigop analysis. This discrepancy leads to consensus divergence when blocks exceed the MAX_BLOCK_SIGOPS threshold on one implementation but not the other. An attacker can exploit this by broadcasting transactions spending P2SH outputs with redeem scripts containing disabled opcodes followed by multiple OP_CHECKSIG or OP_CHECKMULTISIG operations. This causes Zebra validators to accept blocks rejected by zcashd validators, resulting in a chain split. The issue is fixed in Zebra version 4.4.2 by routing the P2SH sigop counting through the same C++ FFI used by the legacy sigop counter, ensuring consistent counting behavior.

The vulnerability causes a consensus split between Zebra and zcashd validators on networks where both participate. Zebra nodes accept blocks with sigop counts under their flawed counting method, while zcashd nodes reject these blocks for exceeding the sigop limit. This split can be triggered by an attacker without mining power or special privileges, simply by broadcasting crafted transactions. Approximately 30% of the current network hashrate using Zebra could mine these divergent blocks, perpetuating the chain split. The attacker incurs only transaction fees to execute this attack.

A patch is available in Zebra version 4.4.2 that corrects the P2SH sigop counting by using the C++ FFI method consistent with the legacy sigop counter. There is no configuration-level workaround; all Zebra nodes validating blocks on networks shared with zcashd are affected until upgraded. Operators should upgrade to Zebra 4.4.2 or later as soon as possible to prevent chain splits.