Which versions of Jwt Attack are affected by CVE-2026-34377?

Zebra cryptocurrency nodes prior to version 4.3.0 are vulnerable to consensus-split attacks by malicious miners, which can isolate affected nodes from the Zcash network and create conditions for…. A patch is available.

How to fix or mitigate CVE-2026-34377?

Within 24 hours: inventory all Zebra node deployments and confirm current versions. Within 7 days: apply Zebra 4.3.0 vendor-released patch to all zebrad and zebra-consensus instances supporting Network Upgrade 5 (V5 transactions); verify patch deployment across all affected systems. Within 30 days: conduct post-patch validation by monitoring node consensus status and network synchronization metrics; document patch deployment and compliance in change management records.

Jwt Attack CVE-2026-34377

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

CVE-2026-34377 has a CVSS 4.0 base score of 8.4 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/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%.

HIGH

Improper Verification of Cryptographic Signature (CWE-347)

2026-03-30 https://github.com/ZcashFoundation/zebra

GHSA-3vmh-33xr-9cqh

Information Disclosure Jwt Attack

8.4

CVSS 4.0 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.4 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/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:H/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/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

High

User Interaction

None

Scope

Lifecycle Timeline

Patch released

Mar 31, 2026 - 21:13 nvd

Patch available

Analysis Generated

Mar 30, 2026 - 19:30 vuln.today

CVE Published

Mar 30, 2026 - 19:13 nvd

HIGH 8.4

DescriptionGitHub Advisory

---

CVE-2026-34377: Consensus Failure via Crafted V5 Authorization Data

Summary

A logic error in Zebra's transaction verification cache could allow a malicious miner to induce a consensus split. By matching a valid transaction's txid while providing invalid authorization data, a miner could cause vulnerable Zebra nodes to accept an invalid block, leading to a consensus split from the rest of the Zcash network. To be clear, this would not allow invalid transactions to be accepted but could result in a consensus split between vulnerable Zebra nodes and invulnerable Zebra and Zcashd nodes.

Severity

High - This is a Consensus Vulnerability that could allow a malicious miner to induce network partitioning, service disruption, and potential double-spend attacks against affected nodes.

Affected Versions

All Zebra versions supporting V5 transactions (Network Upgrade 5 and later) prior to version 4.3.0.

Description

The vulnerability exists in the find_verified_unmined_tx function within transaction.rs. This function was designed to optimize block verification by checking if a transaction was already verified in the mempool.

The lookup mechanism used the ZIP-244 txid as the unique key. However, for V5 transactions, the txid specifically excludes the Authorization Data Root (signatures and proofs). Because Zebra returned a "verified" status based solely on the txid, it skipped the essential check_v5_auth() call for the transaction version provided in the block.

An attacker (specifically a malicious miner) could exploit this by:

Observing a valid V5 transaction broadcast to the network and entering a Zebra node's mempool.
Creating a block containing a modified version of that transaction. The modified version has the same txid but contains invalid signatures or proofs.
The affected Zebra node identifies the txid in its mempool and incorrectly assumes the block's version of the transaction is already verified.
The node commits the block with the invalid transaction data.
Other nodes (like zcashd or zebra nodes without that transaction in their mempool) reject the block, resulting in a chain fork where the poisoned Zebra node is isolated.

Impact

Consensus Failure

Attack Vector: Network (specifically via a malicious miner).
Effect: Network partition/consensus split.
Scope: Any Zebra node utilizing the transaction verification cache optimization for V5 transactions.

Fixed Versions

This issue is fixed in Zebra 4.3.0.

The fix ensures that verification is only skipped if the transaction's full integrity-including authorization data-is validated against the mempool entry.

Mitigation

Users should upgrade to Zebra 4.3.0 or later immediately.

There are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains on the correct consensus path and is protected against malicious chain forks.

Resources

---

AnalysisAI

Zebra cryptocurrency nodes prior to version 4.3.0 can be forced into consensus split by malicious miners who craft blocks containing V5 transactions with matching txids but invalid authorization data. The vulnerability stems from a cache lookup that used ZIP-244 txid (which excludes authorization data) to bypass full verification, allowing nodes to accept blocks with invalid signatures. While this does not enable invalid transaction acceptance, it isolates vulnerable nodes from the Zcash network, creating fork conditions exploitable for service disruption and potential double-spend scenarios against partitioned nodes. No public exploit code or CISA KEV listing exists, but the technical complexity is low for actors with mining capabilities. Affected products are zebrad and zebra-consensus Rust packages supporting Network Upgrade 5 (V5 transactions). Vendor-released patch: Zebra 4.3.0.

Technical ContextAI

This vulnerability exploits the ZIP-244 transaction identifier specification used in Zcash V5 transactions. ZIP-244 defines txid calculation to specifically exclude the Authorization Data Root (signatures and zero-knowledge proofs), creating a separation between transaction structure identity and cryptographic validity. Zebra's find_verified_unmined_tx function in transaction.rs implemented a performance optimization by caching verified transactions from the mempool using txid as the lookup key. When processing blocks, if a matching txid was found in cache, the node skipped the check_v5_auth() call that validates signatures and proofs. This represents CWE-347 (Improper Verification of Cryptographic Signature), where the system trusted structural identity (txid match) as proof of cryptographic validity. The affected Rust packages (pkg:rust/zebrad and pkg:rust/zebra-consensus) form the core consensus layer of Zebra nodes. The vulnerability only affects V5 transaction processing introduced with Network Upgrade 5, making pre-NU5 blocks immune. The cache optimization logic correctly assumed that mempool transactions were fully validated, but failed to account for the scenario where a miner could reference the same txid with substituted authorization data in a block proposal.

RemediationAI

Upgrade immediately to Zebra version 4.3.0 or later, which implements corrected verification logic ensuring authorization data integrity is validated even when transactions match mempool txids. The fix modifies the find_verified_unmined_tx cache lookup to perform full check_v5_auth() validation instead of relying solely on txid matching for verification bypass decisions. Download the patched version from the official Zebra repository and follow standard node upgrade procedures including graceful shutdown, binary replacement, and restart with configuration validation. The Zebra 4.3.0 release announcement at https://zfnd.org/zebra-4-3-0-critical-security-fixes-zip-235-support-and-performance-improvements/ provides detailed upgrade instructions and additional security improvements included in this release. No workarounds exist for this vulnerability as the flaw is fundamental to the transaction verification cache architecture. Node operators running vulnerable versions face consensus isolation risk and should prioritize this upgrade above routine maintenance. After upgrading, verify the node successfully syncs with the canonical Zcash chain by comparing block heights and hashes with reference nodes or block explorers.