GHSA-C8W6-X74F-VMG3

Am I affected

You are affected if:

1. You run zebrad up to and including v4.4.1.
2. Your zebrad.toml sets rpc.listen_addr to a TCP address (RPC server is enabled).
3. An attacker can authenticate to the RPC endpoint. With the default enable_cookie_auth = true, this requires the attacker to read the .cookie file (typically local access). With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

The z_listunifiedreceivers RPC handler panics when processing a structurally valid Unified Address whose Sapling receiver carries 43 bytes that fail cryptographic validation (sapling_crypto::PaymentAddress::from_bytes returns None for non-subgroup Jubjub points). The handler calls .expect("using data already decoded as valid") on the fallible result. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process, not just the RPC task.

Details

zcash_address::unified::Encoding::decode validates only the structural envelope of a Unified Address (F4Jumble, bech32m, typecode ordering, 43-byte length for Sapling). It does not validate that the embedded pk_d is a valid Jubjub subgroup point or that the diversifier produces a valid g_d preimage.

At zebra-rpc/src/methods.rs:2893, the handler calls Address::try_from_sapling(network, data), which delegates to sapling_crypto::PaymentAddress::from_bytes. When from_bytes returns None (most random 32-byte strings fail the subgroup check), the .expect() fires and the process aborts.

The same crate already handles this correctly in try_from_unified at zebra-chain/src/primitives/address.rs:99-110, which returns Err when from_bytes fails. The vulnerable code path bypasses this validated route.

Workarounds

• Disable the RPC server by removing rpc.listen_addr from zebrad.toml.
• Ensure enable_cookie_auth = true (the default) and restrict filesystem access to the .cookie file.
• Place a reverse proxy in front of the RPC port that rejects z_listunifiedreceivers calls with untrusted address parameters.

Credit

Reported by @robustfengbin via a private GitHub Security Advisory submission.

A single authenticated RPC request terminates the zebrad process. The attack is repeatable on restart (the same request triggers the same abort), allowing an attacker to keep the node down indefinitely until the request is filtered upstream. Operators using lightwalletd backends, Zaino indexers, or mining pool infrastructure that forward RPC calls to zebrad may be exposed if the forwarding path passes through z_listunifiedreceivers.

The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths. Typical impact: varies by context: data corruption, logic bypass, or denial of service.

GHSA-C8W6-X74F-VMG3 has a CVSS score of 6.5 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (8.0.0, 4.5.0); upgrading removes the vulnerable code path.

Kodem intelligence

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace .expect() with .map_err(|e| ErrorObject::owned(...)) for proper error propagation, or route through the existing try_from_unified path which already handles this case correctly.

1. What is GHSA-C8W6-X74F-VMG3? GHSA-C8W6-X74F-VMG3 is a medium-severity improper input validation vulnerability in zebra-rpc (rust), affecting versions <= 7.0.0. It is fixed in 8.0.0, 4.5.0. The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths.
2. How severe is GHSA-C8W6-X74F-VMG3? GHSA-C8W6-X74F-VMG3 has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which packages are affected by GHSA-C8W6-X74F-VMG3?
   • zebra-rpc (rust) (versions <= 7.0.0)
   • zebrad (rust) (versions <= 4.4.1)
4. Is there a fix for GHSA-C8W6-X74F-VMG3? Yes. GHSA-C8W6-X74F-VMG3 is fixed in 8.0.0, 4.5.0. Upgrade to this version or later.
5. Is GHSA-C8W6-X74F-VMG3 exploitable, and should I be worried? Whether GHSA-C8W6-X74F-VMG3 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-C8W6-X74F-VMG3 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-C8W6-X74F-VMG3?
   • Upgrade zebra-rpc to 8.0.0 or later
   • Upgrade zebrad to 4.5.0 or later