zcashfoundation/zebra · Security

Zebra's Block Validator Undercounts Coinbase and P2SH Sigops

GHSA ID
GHSA-jv4h-j224-23cc
CVE ID
CVE-2026-44498
Severity
critical
Published
Updated
CVSS
7.5 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
CVSS v3
7.5 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
CVSS v4
9.2 · CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N

Description

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

CWEs

References