VulnerabilityPublished 2 Jul 2026

Zebra rpc: zebrad vulnerable to full node denial of service via crafted Sapling receiver in z_listunifiedreceivers

Affects zebra-rpcSource GCVE Database

CVSS 6.5 Medium : upgrade to 8.0.0 when convenient.

Data as of 3 Jul 2026, 22:49 UTC

CVSS 3.1 base score

6.5Medium

How severe the flaw is on the 0–10 CVSS scale.

Patch: Available – fixed in 8.0.0, 4.5.0

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Attack Vector: Network
Attack Complexity: Low
Privileges Required: Low
User Interaction: None
Scope: Unchanged
Confidentiality: None
Integrity: None
Availability: High

Bold values are the worst case: easiest to exploit or largest impact.

Attack Vector: Network: The vulnerable component is bound to the network stack and the set of possible attackers extends beyond the other options listed, up to and including the entire Internet. Such a vulnerability is often termed 'remotely exploitable' and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
Attack Complexity: Low: Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.
Privileges Required: Low: The attacker is authorized with (i.e., requires) privileges that provide basic user capabilities that could normally affect only settings and files owned by a user. Alternatively, an attacker with Low privileges may have the ability to cause an impact only to non-sensitive resources.
User Interaction: None: The vulnerable system can be exploited without any interaction from any user.
Scope: Unchanged: An exploited vulnerability can only affect resources managed by the same security authority. In this case, the vulnerable component and the impacted component are either the same, or both are managed by the same security authority.
Confidentiality: None: There is no loss of confidentiality within the impacted component.
Integrity: None: There is no loss of integrity within the impacted component.
Availability: High: There is total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable).

Definitions: FIRST CVSS v3.1 specification.

What to do

Upgrade zebra-rpc to 8.0.0; zebrad to 4.5.0.

Affected software

Product	Affected	Fixed in
crates.iozebra-rpc	Affected <8.0.0	Fixed in 8.0.0
crates.iozebrad	Affected <4.5.0	Fixed in 4.5.0

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

A fix is available in zebrad 4.5.0 and zebra-rpc 8.0.0 that properly handles invalid Sapling receiver data without panicking. Until patched, operators should disable the RPC server by removing rpc.listen_addr from zebrad.toml, ensure enable_cookie_auth is true and restrict access to the .cookie file, or place a reverse proxy in front of the RPC port to filter out malicious z_listunifiedreceivers calls. These mitigations prevent unauthenticated or unauthorized triggering of the vulnerability.

Description

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

Impact

An authenticated attacker can send a single crafted RPC request to the z_listunifiedreceivers handler that causes the zebrad node process to abort immediately, resulting in a denial of service. The attack can be repeated indefinitely, preventing the node from operating until the malicious requests are blocked or the RPC server is disabled. This impacts node availability but does not affect confidentiality or integrity.

Summary

The z_listunifiedreceivers RPC handler in zebrad versions up to and including v4.4.1 improperly handles structurally valid but cryptographically invalid Sapling receivers embedded in Unified Addresses. Specifically, the handler calls a function that returns None for invalid Jubjub subgroup points but uses .expect() on this result, causing a panic and process abort when invalid data is encountered. Because zebrad is compiled with panic = "abort", this terminates the entire node process, not just the RPC task. The vulnerability requires RPC authentication, which by default requires local access to the .cookie file, but can be exposed remotely if cookie authentication is disabled. The issue is fixed in zebra-rpc 8.0.0 and zebrad 4.5.0 by replacing the panic with proper error propagation.

CWE-20Improper Input Validation (opens in a new tab)
Class weaknessLikelihood of exploit: HighCWE Top 25 (2025): #18OWASP Top 10 A05:2025: Injection (opens in a new tab)
The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.
MITRE discourages mapping vulnerabilities to this broad entry; the root cause is usually a more specific weakness.
Architecture and Design · Attack Surface Reduction
Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of…
Architecture and Design · Libraries or Frameworks
Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).
Architecture and Design · Implementation · Attack Surface Reduction
Understand all the potential areas where untrusted inputs can enter the product, including but not limited to: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any…
OWASP Cheat Sheets
XML Security (opens in a new tab)
Mass Assignment (opens in a new tab)
Injection Prevention (opens in a new tab)
SQL Injection Prevention (opens in a new tab)
Injection Prevention in Java (opens in a new tab)
OWASP ASVS 4.0.3
V13.3.1 (opens in a new tab)
V5.1.4 (opens in a new tab)
V5.1.3 (opens in a new tab)
Attack patterns
Buffer Overflow via Environment Variables (opens in a new tab)
Server Side Include (SSI) Injection (opens in a new tab)
Cross Zone Scripting (opens in a new tab)
Command Line Execution through SQL Injection (opens in a new tab)
Object Relational Mapping Injection (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).
CWE-248Uncaught Exception (opens in a new tab)
Base weaknessOWASP Top 10 A10:2025: Mishandling of Exceptional Conditions (opens in a new tab)
An exception is thrown from a function, but it is not caught.
Requirements
The choice between a language which has named or unnamed exceptions needs to be done. While unnamed exceptions exacerbate the chance of not properly dealing with an exception, named exceptions suffer from the up call version of the weak base class problem.
Requirements
A language can be used which requires, at compile time, to catch all serious exceptions. However, one must make sure to use the most current version of the API as new exceptions could be added.
Implementation
Catch all relevant exceptions. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment.
OWASP Cheat Sheets
Logging (opens in a new tab)
Error Handling (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).
CWE-617Reachable Assertion (opens in a new tab)
Base weakness
The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.
Implementation
If the assertion statement is required (e.g., for security or reliability), change the invoking code to avoid the conditions that trigger the assertion.
Implementation
Consider changing the assertion to some other less "fatal" error. This might not be easy to implement, since other code may be needed to handle the error.
Implementation
Make sensitive open/close operations non-reachable from directly user-controlled data (e.g. open/close resources)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).
CWE-754Improper Check for Unusual or Exceptional Conditions (opens in a new tab)
Class weaknessLikelihood of exploit: MediumOWASP Top 10 A10:2025: Mishandling of Exceptional Conditions (opens in a new tab)
The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
Requirements · Language Selection
Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
Implementation
Check the results of all functions that return a value and verify that the value is expected.
Implementation
If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248).
OWASP Cheat Sheets
Logging (opens in a new tab)
Error Handling (opens in a new tab)
OWASP ASVS 4.0.3
V11.1.7 (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

References

Community reviews

Loading reviews…

What to do

Affected software

Description

AI analysisMachine-generated, updated 2 Jul 2026, 23:11 UTC

WeaknessesCWE-20, CWE-248, CWE-617 +1

Technical details

References

Community reviews

Related threats