ZEBRAD · CVE-2026-44498 · Package
FIX → 4.4.0
Zebra's block validator undercounts transparent signature operations against the 20000 block limit, so it accepts blocks that zcashd rejects. A miner can use this to split the network, with Zebra nodes following a chain that zcashd nodes refuse.
first public May 2, 2026 · 2 sources
Check it with your coding agent
It reads this page and tells you if your code or app is affected.
Operators who run Zebra nodes and rely on them for consensus validation on the Zcash network are affected, because a block the sources say zcashd rejects can be accepted by Zebra. The sources state no workaround, so the fix is to upgrade. Nodes that do not validate Zcash blocks with Zebra are not exposed.
Not affected if not-zcash-node, zcashd-only
Who cares cargo, self-hosted, zcash, zebra
zebrad --version; versions below 4.4.0 are affected.Upgrade to 4.4.0
4.4.0 or later.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:
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.
zcashd's GetP2SHSigOpCount() parses each P2SH input's redeem script with and sums those sigops into the block-wide total via . 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 .
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
InfraStack checks it against your stack and answers on your report, with the evidence and the fix.
accurate=trueConnectBlockzcashdFixed in this release: https://github.com/ZcashFoundation/zebra/releases/tag/v4.4.0.
None. Operators relying on Zebra for consensus should upgrade.
MAX_BLOCK_SIGOPS constant 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.zcashd GetLegacySigOpCount: https://github.com/zcash/zcash/blob/v6.11.0/src/main.cpp#L826-L836zcashd GetP2SHSigOpCount: https://github.com/zcash/zcash/blob/v6.11.0/src/main.cpp#L840-L852zcashd ConnectBlock aggregates per-tx sigops and compares against MAX_BLOCK_SIGOPS.This page as .md · .json · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.