Raw vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/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:XSummary
CVE-2026-34202 is a critical-severity Code Injection (CWE-94) vulnerability in Zfnd Zebra. Its CVSS base score is 9.2 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Template Injection (T1221); ranked in the top 49% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-34202 is a vulnerability in Zebra, a Zcash node implementation written entirely in Rust, affecting zebrad versions prior to 4.3.0 and zebra-chain versions prior to 6.0.1. The flaw resides in Zebra's transaction processing logic, where a specially crafted V5 transaction can pass initial deserialization but trigger a failure during transaction ID calculation, causing the node to panic and crash. It is associated with CWEs-94 (code injection), CWE-1336, and CWE-502 (deserialization of untrusted data), and carries a CVSS v3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
A remote, unauthenticated attacker can exploit this vulnerability by sending the malicious V5 transaction to a vulnerable Zebra node over the network. Successful exploitation results in a denial-of-service condition, as the node crashes due to the panic, disrupting its availability for transaction validation and blockchain synchronization without impacting confidentiality or integrity.
The issue has been patched in zebrad version 4.3.0 and zebra-chain version 6.0.1. Security advisories recommend immediate upgrading to these fixed versions to mitigate the risk. Additional details are available in the GitHub release notes (https://github.com/ZcashFoundation/zebra/releases/tag/v4.3.0), the security advisory (https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-qp6f-w4r3-h8wg), and the Zcash Foundation announcement (https://zfnd.org/zebra-4-3-0-critical-security-fixes-zip-235-support-and-performance-improvements).
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-17453
Vulnerability Data
ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.3.0 and zebra-chain version 6.0.1, a vulnerability in Zebra's transaction processing logic allows a remote, unauthenticated attacker to cause a Zebra node to panic (crash). This is…
more
triggered by sending a specially crafted V5 transaction that passes initial deserialization but fails during transaction ID calculation. This issue has been patched in zebrad version 4.3.0 and zebra-chain version 6.0.1.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.3.2V1.3.7V1.3.10V1.3.1
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation finds code paths that accept and execute externally influenced strings.
Input validation directly stops untrusted data from being used to construct executable code without neutralization.
Least privilege limits the damage an injected code fragment can perform once executed.
Requiring documented secure development standards and tools enforces use of safe code-generation APIs and escaping.
Security engineering principles require use of safe templating APIs and proper escaping of external input.
Integrity verification tools can detect malformed or tampered serialized data after the fact.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
PR.PS-06's SDLC practices directly target injection flaws via secure coding and testing (mostly), yet as a single broad outcome it leaves many code-generation specifics unaddressed (partial).
PR.DS-10 protects runtime data confidentiality/integrity but has no bearing on neutralizing externally influenced input during code generation, so neither direction shows any preventive effect.
PR.PS-02 addresses only post-deployment updates/patching and cannot prevent introduction of unsafe deserialization code, yet it can remediate some instances when the flaw exists in outdated libraries or components.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect template-injection flaws but does not itself implement neutralization controls.
Secure development life cycle mandates input validation and sanitization that directly prevents template-injection weaknesses.
Application security requirements explicitly call for neutralizing special elements in template engines.
Secure architecture principles reduce the likelihood of unsafe template processing but do not prescribe specific neutralization techniques.
Banning unapproved code samples and unauthenticated web services, combined with secure-coding standards and SAST, prevents the dynamic generation or inclusion of attacker-supplied code.
Regular scanning of third-party libraries and timely patching reduce the likelihood that unsafe deserialization vulnerabilities remain active.