# Zebra 6.4.2: Emergency Fix for a Remotely Triggerable Crash **URL:** \ **Category:** Zcash Foundation\ **Created:** [September 28, 2026, 5:45pm UTC](https://forum.zcashcommunity.com/t/zebra-6-4-2-emergency-fix-for-a-remotely-triggerable-crash/57872 "2026-09-28T17:45:05Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![ZcashFoundation](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zcashfoundation/32/21548_2.png) [@ZcashFoundation](https://forum.zcashcommunity.com/u/ZcashFoundation)\ **Post date:** [September 28, 2026, 5:45pm UTC](https://forum.zcashcommunity.com/t/zebra-6-4-2-emergency-fix-for-a-remotely-triggerable-crash/57872/1 "2026-09-28T17:45:06Z")
Zebra 6.4.2 is an emergency security release that fixes a high-severity vulnerability in Zebra 6.4.0 and 6.4.1 that lets any peer crash a node with a single network message. Both of those versions are recalled, and all operators running either one should upgrade to 6.4.2 immediately. Zebra 6.3.0 and earlier are not affected by this issue. Zebra 6.4.2 also includes the sync stall fix shipped in 6.4.1. ## **Security Advisories** ### [GHSA-h5rr-8pqv-grp9](https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-h5rr-8pqv-grp9): Remote Crash via Malformed v6 Transaction (High) Zebra 6.4.0 moved transaction parsing to the shared `zcash_primitives` library, and in the process dropped a check that rejects v6 transactions carrying a consensus branch ID from before NU6.3. Zebra could parse such a transaction but not re-serialize it, and it re-serializes every transaction it receives to compute its size, treating that step as infallible. A single malformed `tx` message from any peer therefore terminated the node. The attack needs no authentication, no completed handshake, and no special configuration, and a peer could repeat it immediately after each restart to keep a node down. No configuration change removes the exposure. The impact is availability only, with no consensus or funds impact. Zebra 6.4.2 restores the parse-time check, so these transactions are rejected as soon as they are received. This issue was first found by [Google OSS-Fuzz](https://google.github.io/oss-fuzz/) through Zebra’s continuous fuzzing. Thanks to [@SphereDonout](https://github.com/SphereDonout) and [@v12security](https://github.com/v12security) for independently reporting this issue after it shipped in Zebra 6.4.0. ## **Recalled Releases** ### Zebra 6.4.0 and 6.4.1 Zebra 6.4.0 and 6.4.1 are recalled and should not be run or deployed. Their GitHub release pages now carry a recall notice, their `zfnd/zebra` Docker tags have been removed, and the corresponding `zebrad` versions have been yanked from [crates.io](http://crates.io). Every feature and fix introduced in 6.4.0 and 6.4.1 is included in 6.4.2, so upgrading loses nothing. ## **Upgrading** ### How to Upgrade Operators should upgrade to Zebra 6.4.2 now. The release is available from: - [GitHub releases](https://github.com/ZcashFoundation/zebra/releases/tag/v6.4.2), with pre-built Linux binaries for x86\_64 and aarch64 - [crates.io](https://crates.io/crates/zebrad) - [Docker Hub](https://hub.docker.com/r/zfnd/zebra) as `zfnd/zebra:6.4.2` ### Library Consumers The fix is in `zebra-chain` v13.0.1. Applications that use earlier `zebra-chain` releases from the 6.4.x line to deserialize transactions from untrusted sources should upgrade. ## **Contributors** Thank you to everyone who contributed to this release: - [@jvff](https://github.com/jvff) _Zebra is the Zcash Foundation’s independent, Rust-based implementation of the Zcash protocol. Learn more at [github.com/ZcashFoundation/zebra](https://github.com/ZcashFoundation/zebra)._ ---
**Author:** ![DrVelvetFog](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/drvelvetfog/32/48442_2.png) [@DrVelvetFog](https://forum.zcashcommunity.com/u/DrVelvetFog)\ **Post date:** [October 9, 2026, 1:49pm UTC](https://forum.zcashcommunity.com/t/zebra-6-4-2-emergency-fix-for-a-remotely-triggerable-crash/57872/2 "2026-10-09T13:49:27Z")
Worth adding for anyone building on zcash\_primitives directly: 6.4.2 fixes this at the node (the parse-time floor), but the underlying read/write asymmetry is still open in the library — tracked at [zcash\_primitives: v6 Orchard bundle read/write asymmetry (pre-NU6.3 branch IDs) · Issue #3115 · zcash/librustzcash · GitHub](https://github.com/zcash/librustzcash/issues/3115). Any downstream that parses untrusted v6 transactions and assumes “read succeeded ⇒ write succeeds” inherits the same failure shape until that lands. The catch pattern is cheap: a decode → re-encode round-trip oracle turns the whole class into a mechanical check — that’s how OSS-Fuzz found this one — and it travels to any codec where parse and serialize evolve separately.