---
id: "GHSA-c8w6-x74f-vmg3"
page: "https://infrastack.ai/live/GHSA-c8w6-x74f-vmg3"
kind: "vulnerability"
aliases: ["GHSA-c8w6-x74f-vmg3"]
title: "zebrad vulnerable to full node denial of service via crafted Sapling receiver in z_listunifiedreceivers"
severity: "medium"
cvss: 6.5
epss: null
exploited: false
status: "open"
category: "package"
products: [{"name": "zebra-rpc", "fixed": ["8.0.0"], "affected": "<= 7.0.0", "ecosystem": "cargo"}, {"name": "zebrad", "fixed": ["4.5.0"], "affected": "<= 4.4.1", "ecosystem": "cargo"}]
ecosystems: ["cargo"]
tags: ["cwe-20", "cwe-248", "cwe-617", "cwe-754", "lightwalletd", "mining-pool", "package", "zcash", "zebra-rpc", "zebrad"]
not_affected_if: ["cookie-auth-default", "no-forwarding-of-z_listunifiedreceivers", "rpc-disabled"]
published_at: "2026-07-02T19:37:58+00:00"
first_seen_at: "2026-11-13T02:48:40+00:00"
updated_at: "2026-11-13T02:49:09+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-c8w6-x74f-vmg3", "first_seen_at": "2026-11-13T02:48:40+00:00"}]
exploit_sources: []
---

# zebrad vulnerable to full node denial of service via crafted Sapling receiver in z_listunifiedreceivers

Link for people: https://infrastack.ai/live/GHSA-c8w6-x74f-vmg3 (this .md is for agents)

A crafted Unified Address passed to the z_listunifiedreceivers RPC call makes the zebrad process panic and exit. A single authenticated request keeps the node down until restarted and the request is filtered.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- cargo:zebra-rpc affected <= 7.0.0 fixed 8.0.0
- cargo:zebrad affected <= 4.4.1 fixed 4.5.0

## How to check

- Check the installed version with `zebrad --version`; affected versions are up to and including `4.4.1`.
- Look in `zebrad.toml` for `rpc.listen_addr`; the RPC server is only exposed when it is set.
- Check whether `enable_cookie_auth` is `true` (the default) or `false`; with `false`, any network client reaching the RPC port can trigger the crash.

## Fix

- `zebrad`: upgrade to `4.5.0`.
- `zebra-rpc` (cargo): upgrade to `8.0.0`.

## Timeline

- 2026-11-13T02:48:40+00:00 ghsa https://github.com/advisories/GHSA-c8w6-x74f-vmg3

## Documents

- [advisory] Maintainer's advisory: api.github.com https://api.github.com/repos/ZcashFoundation/zebra/security-advisories/GHSA-c8w6-x74f-vmg3
- [advisory] Maintainer's advisory: github.com https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-c8w6-x74f-vmg3

## From the sources

### 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.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_