CVE-2026-44498: Zebra's Block Validator Undercounts Coinbase and P2SH Sigops
Zebra's block validator undercounts transparent signature operations against the 20000-sigop block limit (MAXBLOCKSIGOPS), allowing it to accept blocks that zcashd rejects with bad-blk-sigops. A miner who produces such a block can split the network: Zebra nodes follow the offending chain while zcashd nodes do not.
Published May 7, 2026 · Updated May 13, 2026
Affected packages
zebrad
- Ecosystem
- Rust (crates.io)
- Affected
- < 4.4.0
- Fixed in
- 4.4.0
- Check
cargo tree -i zebrad
Advisory details
From the GitHub Advisory Database (CC BY 4.0).
Zebra's block validator undercounts transparent signature operations against the 20000-sigop block limit (MAX_BLOCK_SIGOPS), allowing it to accept blocks that zcashd rejects with bad-blk-sigops. A miner who produces such a block can split the network: Zebra nodes follow the offending chain while zcashd nodes do not.
Two distinct undercounts:
A: Coinbase Hidden Legacy Sigops
zcashd's GetLegacySigOpCount() includes the coinbase input's scriptSig. Zebra's Sigops impl skipped the coinbase input entirely, so up to ~98 sigops (the 100-byte coinbase script length cap, less the height prefix) could be hidden inside the coinbase scriptSig without being charged against the block limit.
B: Aggregate P2SH Sigops.
zcashd's GetP2SHSigOpCount() parses each P2SH input's redeem script with accurate=true and sums those sigops into the block-wide total via ConnectBlock. The check is per-block, not per-transaction, and the limit applies regardless of who mines the offending block — a miner just needs to include enough P2SH-spending transactions whose redeem scripts together exceed 20000 sigops. Zebra computed P2SH sigops only on the mempool-acceptance path (used for ZIP-317 weighting) and never accumulated them during block validation. A block whose aggregate redeem-script sigops exceed 20000 (e.g. 1334 P2SH spends × 15 sigops = 20010) would be accepted by Zebra and rejected by zcashd.
Patches
Fixed in this release: https://github.com/ZcashFoundation/zebra/releases/tag/v4.4.0.
Workarounds
None. Operators relying on Zebra for consensus should upgrade.
Resources
MAX_BLOCK_SIGOPSconstant inherited from Bitcoin via the Zcash protocol spec's §7.6 catch-all "Other rules inherited from Bitcoin", tracked for explicit documentation in zcash/zips#568.zcashdGetLegacySigOpCount:zcashdGetP2SHSigOpCount:zcashdConnectBlockaggregates per-tx sigops and compares againstMAX_BLOCK_SIGOPS.
Credited to sangsoo-osec, upbqdn, mpguerra, defuse.
References
How this page is made: the data panel comes from the GitHub Advisory Database, CISA’s KEV catalog, the NVD and FIRST EPSS, and updates twice a day. No analysis has been written for this entry yet. Methodology
More Rust (crates.io) vulnerabilities
All Rust (crates.io) entriesCVE-2026-54496
Zebra: Missing copy constraint in halo2_gadgets variable-base scalar multiplication allows under-constrained base, breaking Orchard Action circuit soundness
critical9.3Jul 6, 2026CVE-2026-52735
zebrad has consensus divergence via P2SH sigop undercount in pure-Rust disabled-opcode parser
critical9.3Jul 2, 2026GHSA-pvmv-cwg8-v6c8
Zebra v4.4.0 still accepts V5 SIGHASH_SINGLE without a corresponding output
critical9.3May 8, 2026CVE-2026-44497
Zebra has Consensus Divergence in Transparent Sighash Hash-Type Handling due to Stale Buffer
critical9.1May 7, 2026GHSA-cwfq-rfcr-8hmp
Zebra's Transparent SIGHASH_SINGLE Handling Diverges from zcashd for Corresponding Outputs
critical9.2May 7, 2026CVE-2026-41583
Zebra Vulnerable to Consensus Divergence in Transparent Sighash Hash-Type Handling
critical9.1Apr 18, 2026
