Which versions of Zebra are affected by CVE-2026-44498?

Zebra's block validator contains critical flaws in signature operation counting that allow malicious miners to create blocks exceeding consensus limits, causing network partitions between Zebra and…. A patch is available.

How to fix or mitigate CVE-2026-44498?

Within 24 hours: Identify all Zebra deployments running versions prior to 4.4.0 and assess their criticality to Zcash network participation. Within 7 days: Deploy Zebra 4.4.0 to all affected instances; coordinate upgrade timing with network operators to minimize consensus disruption. Within 30 days: Complete upgrade verification and validate block acceptance consistency with reference zcashd nodes in production environment.

Zebra CVE-2026-44498

Q: What is the CVSS score of CVE-2026-44498?

CVE-2026-44498 has a CVSS 4.0 base score of 9.2 (Critical). CVSS vector: 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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

CRITICAL

Incorrect Calculation (CWE-682)

2026-05-07 https://github.com/ZcashFoundation/zebra

GHSA-jv4h-j224-23cc

Information Disclosure

9.2

CVSS 4.0 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

9.2 CRITICAL

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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Re-analysis Queued

May 08, 2026 - 15:22 vuln.today

cvss_changed

CVSS changed

May 08, 2026 - 15:22 NVD

9.2 (CRITICAL)

Source Code Evidence Fetched

May 07, 2026 - 21:16 vuln.today

Analysis Generated

May 07, 2026 - 21:16 vuln.today

CVE Published

May 07, 2026 - 20:54 nvd

CRITICAL

DescriptionGitHub Advisory

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_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-L836>
zcashd GetP2SHSigOpCount: <https://github.com/zcash/zcash/blob/v6.11.0/src/main.cpp#L840-L852>
zcashd ConnectBlock aggregates per-tx sigops and compares against MAX_BLOCK_SIGOPS.

AnalysisAI

Zebra's block validator fails to count transparent signature operations correctly, allowing malicious miners to create blocks that exceed the 20,000 sigop consensus limit and trigger network splits between Zebra and zcashd nodes. The vulnerability affects Zebra versions prior to 4.4.0 and stems from two distinct accounting flaws: (1) coinbase input scriptSigs were excluded from legacy sigop counts, hiding up to 98 operations, and (2) P2SH redeem script sigops were only computed during mempool validation but never aggregated during block validation. A miner could craft a single block with 1,334+ P2SH spends to exceed the limit and partition the Zcash network. Vendor-released patch: Zebra 4.4.0 (confirmed by GitHub advisory GHSA-jv4h-j224-23cc). No public exploit identified at time of analysis.

Technical ContextAI

The vulnerability manifests in Zebra's implementation of the MAX_BLOCK_SIGOPS consensus rule, a 20,000 signature operation limit inherited from Bitcoin and specified in Zcash protocol §7.6. Zebra (written in Rust, package pkg:rust/zebrad) implements an independent block validator that must maintain byte-for-byte consensus compatibility with the canonical zcashd (C++) implementation. The root cause (CWE-682: Incorrect Calculation) is a double accounting divergence: Zebra's Sigops trait skipped the coinbase transaction's input entirely when calling GetLegacySigOpCount, failing to parse the scriptSig which can hold up to 98 sigops within the 100-byte coinbase script length cap. Separately, Zebra computed P2SH (Pay-to-Script-Hash) redeem script sigops only in the mempool acceptance path for ZIP-317 transaction weighting but never invoked GetP2SHSigOpCount or aggregated sigops across all inputs during ConnectBlock validation. This allowed a block containing many P2SH-spending transactions (each redeem script contributing 15 sigops, for example) to pass Zebra's validator while zcashd's ConnectBlock would correctly sum the aggregate and reject with bad-blk-sigops. The consensus split arises because blockchain nodes must agree on every block's validity to maintain a single chain.

RemediationAI

Upgrade to Zebra 4.4.0 immediately, available at https://github.com/ZcashFoundation/zebra/releases/tag/v4.4.0. The GitHub advisory GHSA-jv4h-j224-23cc explicitly states no workarounds exist and that operators relying on Zebra for consensus must upgrade. The patch implements two fixes: (1) modifies the Sigops trait to include coinbase input scriptSig parsing in legacy sigop counts, aligning with zcashd's GetLegacySigOpCount behavior, and (2) adds P2SH redeem script sigop aggregation to the block validation path (ConnectBlock equivalent) rather than limiting it to mempool checks. For environments where immediate upgrade is not feasible, the ONLY temporary risk reduction is to switch to zcashd nodes until Zebra can be patched, as zcashd correctly enforces the 20,000 sigop limit and will not follow a malicious chain. Running mixed Zebra/zcashd infrastructure does NOT mitigate the risk-a single malicious block will still partition the network. There are no configuration-based mitigations; the vulnerability is in core consensus logic. Review release notes at the tag URL for additional security fixes shipped in 4.4.0 (GHSA-gq4h-3grw-2rhv, GHSA-438q-jx8f-cccv, GHSA-jg86-rwhm-fhg4) that warrant the upgrade beyond this CVE alone.