PT-2026-57593 · Crates.Io · Zebra-Rpc+1

Published

2026-07-02

·

Updated

2026-07-02

CVSS v3.1

6.5

Medium

VectorAV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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.

Summary

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.

Patches

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.

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.

Impact

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.

Credit

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

Fix

Assertion Failure

Improper Check for Exceptional Conditions

RCE

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Weakness Enumeration

CWE-617CWE-754CWE-20CWE-248

Related Identifiers

GHSA-C8W6-X74F-VMG3

Affected Products

Zebra-Rpc
Zebrad