zebra-rpc

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

A vulnerability in Zebra's JSON-RPC HTTP middleware allows an authenticated RPC client to cause a Zebra node to crash by disconnecting before the request body is fully received. The node treats the failure to read the HTTP request body as an unrecoverable error and aborts the process instead of returning an error response.

Severity

Moderate - This is a Denial of Service (DoS) that requires a client capable of passing Zebra's cookie authentication, which is enabled by default.

Affected Versions

• zebrad: versions from 2.2.0 up to (but not including) 4.3.1
• zebra-rpc: versions from 1.0.0-beta.45 up to (but not including) 6.0.2

Description

Zebra's JSON-RPC HTTP middleware treated a failure to read the incoming HTTP request body as an unrecoverable error, aborting the process rather than returning an error response. A client that disconnected after sending only part of a request body, for example, by resetting the TCP connection mid-transfer, was sufficient to trigger the crash. The vulnerability could be exploited only by authenticated RPC clients. Nodes running the shipped defaults, with RPC bound to localhost and cookie authentication on, were not vulnerable.

Impact

Denial of Service

• Attack Vector: Network, authenticated (requires a valid RPC cookie when cookie authentication is enabled).
• Effect: Immediate crash of the Zebra node.
• Scope: Any node whose RPC interface is reachable by a client with valid credentials, or any node with cookie authentication disabled and an exposed RPC interface.

Fixed Versions

This issue is fixed in Zebra 4.3.1 (crate zebra-rpc 6.0.2).

The fix propagates failures to read the HTTP request body as ordinary error responses, so Zebra now rejects truncated or interrupted requests rather than crashing.

Mitigation

Users should upgrade to Zebra 4.3.1 or later.

If an immediate upgrade is not possible, users should ensure their RPC port is not exposed to untrusted networks and that cookie authentication remains enabled (the default).

References

• Zebra 4.3.1 Release Announcement

Credits

Thanks to shieldedonly who discovered this issue and reported it via our coordinated disclosure process.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

A vulnerability in Zebra's JSON-RPC HTTP middleware allows an authenticated RPC client to cause a Zebra node to crash by disconnecting before the request body is fully received. The node treats the failure to read the HTTP request body as an unrecoverable error and aborts the process instead of returning an error response.

Severity

Moderate - This is a Denial of Service (DoS) that requires a client capable of passing Zebra's cookie authentication, which is enabled by default.

Affected Versions

• zebrad: versions from 2.2.0 up to (but not including) 4.3.1
• zebra-rpc: versions from 1.0.0-beta.45 up to (but not including) 6.0.2

Description

Zebra's JSON-RPC HTTP middleware treated a failure to read the incoming HTTP request body as an unrecoverable error, aborting the process rather than returning an error response. A client that disconnected after sending only part of a request body, for example, by resetting the TCP connection mid-transfer, was sufficient to trigger the crash. The vulnerability could be exploited only by authenticated RPC clients. Nodes running the shipped defaults, with RPC bound to localhost and cookie authentication on, were not vulnerable.

Impact

Denial of Service

• Attack Vector: Network, authenticated (requires a valid RPC cookie when cookie authentication is enabled).
• Effect: Immediate crash of the Zebra node.
• Scope: Any node whose RPC interface is reachable by a client with valid credentials, or any node with cookie authentication disabled and an exposed RPC interface.

Fixed Versions

This issue is fixed in Zebra 4.3.1 (crate zebra-rpc 6.0.2).

The fix propagates failures to read the HTTP request body as ordinary error responses, so Zebra now rejects truncated or interrupted requests rather than crashing.

Mitigation

Users should upgrade to Zebra 4.3.1 or later.

If an immediate upgrade is not possible, users should ensure their RPC port is not exposed to untrusted networks and that cookie authentication remains enabled (the default).

References

• Zebra 4.3.1 Release Announcement

Credits

Thanks to shieldedonly who discovered this issue and reported it via our coordinated disclosure process.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

A vulnerability in Zebra's JSON-RPC HTTP middleware allows an authenticated RPC client to cause a Zebra node to crash by disconnecting before the request body is fully received. The node treats the failure to read the HTTP request body as an unrecoverable error and aborts the process instead of returning an error response.

Severity

Moderate - This is a Denial of Service (DoS) that requires a client capable of passing Zebra's cookie authentication, which is enabled by default.

Affected Versions

• zebrad: versions from 2.2.0 up to (but not including) 4.3.1
• zebra-rpc: versions from 1.0.0-beta.45 up to (but not including) 6.0.2

Description

Zebra's JSON-RPC HTTP middleware treated a failure to read the incoming HTTP request body as an unrecoverable error, aborting the process rather than returning an error response. A client that disconnected after sending only part of a request body, for example, by resetting the TCP connection mid-transfer, was sufficient to trigger the crash. The vulnerability could be exploited only by authenticated RPC clients. Nodes running the shipped defaults, with RPC bound to localhost and cookie authentication on, were not vulnerable.

Impact

Denial of Service

• Attack Vector: Network, authenticated (requires a valid RPC cookie when cookie authentication is enabled).
• Effect: Immediate crash of the Zebra node.
• Scope: Any node whose RPC interface is reachable by a client with valid credentials, or any node with cookie authentication disabled and an exposed RPC interface.

Fixed Versions

This issue is fixed in Zebra 4.3.1 (crate zebra-rpc 6.0.2).

The fix propagates failures to read the HTTP request body as ordinary error responses, so Zebra now rejects truncated or interrupted requests rather than crashing.

Mitigation

Users should upgrade to Zebra 4.3.1 or later.

If an immediate upgrade is not possible, users should ensure their RPC port is not exposed to untrusted networks and that cookie authentication remains enabled (the default).

References

• Zebra 4.3.1 Release Announcement

Credits

Thanks to shieldedonly who discovered this issue and reported it via our coordinated disclosure process.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

A vulnerability in Zebra's JSON-RPC HTTP middleware allows an authenticated RPC client to cause a Zebra node to crash by disconnecting before the request body is fully received. The node treats the failure to read the HTTP request body as an unrecoverable error and aborts the process instead of returning an error response.

Severity

Moderate - This is a Denial of Service (DoS) that requires a client capable of passing Zebra's cookie authentication, which is enabled by default.

Affected Versions

• zebrad: versions from 2.2.0 up to (but not including) 4.3.1
• zebra-rpc: versions from 1.0.0-beta.45 up to (but not including) 6.0.2

Description

Zebra's JSON-RPC HTTP middleware treated a failure to read the incoming HTTP request body as an unrecoverable error, aborting the process rather than returning an error response. A client that disconnected after sending only part of a request body, for example, by resetting the TCP connection mid-transfer, was sufficient to trigger the crash. The vulnerability could be exploited only by authenticated RPC clients. Nodes running the shipped defaults, with RPC bound to localhost and cookie authentication on, were not vulnerable.

Impact

Denial of Service

• Attack Vector: Network, authenticated (requires a valid RPC cookie when cookie authentication is enabled).
• Effect: Immediate crash of the Zebra node.
• Scope: Any node whose RPC interface is reachable by a client with valid credentials, or any node with cookie authentication disabled and an exposed RPC interface.

Fixed Versions

This issue is fixed in Zebra 4.3.1 (crate zebra-rpc 6.0.2).

The fix propagates failures to read the HTTP request body as ordinary error responses, so Zebra now rejects truncated or interrupted requests rather than crashing.

Mitigation

Users should upgrade to Zebra 4.3.1 or later.

If an immediate upgrade is not possible, users should ensure their RPC port is not exposed to untrusted networks and that cookie authentication remains enabled (the default).

References

• Zebra 4.3.1 Release Announcement

Credits

Thanks to shieldedonly who discovered this issue and reported it via our coordinated disclosure process.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

A vulnerability in Zebra's JSON-RPC HTTP middleware allows an authenticated RPC client to cause a Zebra node to crash by disconnecting before the request body is fully received. The node treats the failure to read the HTTP request body as an unrecoverable error and aborts the process instead of returning an error response.

Severity

Moderate - This is a Denial of Service (DoS) that requires a client capable of passing Zebra's cookie authentication, which is enabled by default.

Affected Versions

• zebrad: versions from 2.2.0 up to (but not including) 4.3.1
• zebra-rpc: versions from 1.0.0-beta.45 up to (but not including) 6.0.2

Description

Zebra's JSON-RPC HTTP middleware treated a failure to read the incoming HTTP request body as an unrecoverable error, aborting the process rather than returning an error response. A client that disconnected after sending only part of a request body, for example, by resetting the TCP connection mid-transfer, was sufficient to trigger the crash. The vulnerability could be exploited only by authenticated RPC clients. Nodes running the shipped defaults, with RPC bound to localhost and cookie authentication on, were not vulnerable.

Impact

Denial of Service

• Attack Vector: Network, authenticated (requires a valid RPC cookie when cookie authentication is enabled).
• Effect: Immediate crash of the Zebra node.
• Scope: Any node whose RPC interface is reachable by a client with valid credentials, or any node with cookie authentication disabled and an exposed RPC interface.

Fixed Versions

This issue is fixed in Zebra 4.3.1 (crate zebra-rpc 6.0.2).

The fix propagates failures to read the HTTP request body as ordinary error responses, so Zebra now rejects truncated or interrupted requests rather than crashing.

Mitigation

Users should upgrade to Zebra 4.3.1 or later.

If an immediate upgrade is not possible, users should ensure their RPC port is not exposed to untrusted networks and that cookie authentication remains enabled (the default).

References

• Zebra 4.3.1 Release Announcement

Credits

Thanks to shieldedonly who discovered this issue and reported it via our coordinated disclosure process.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

A vulnerability in Zebra's JSON-RPC HTTP middleware allows an authenticated RPC client to cause a Zebra node to crash by disconnecting before the request body is fully received. The node treats the failure to read the HTTP request body as an unrecoverable error and aborts the process instead of returning an error response.

Severity

Moderate - This is a Denial of Service (DoS) that requires a client capable of passing Zebra's cookie authentication, which is enabled by default.

Affected Versions

• zebrad: versions from 2.2.0 up to (but not including) 4.3.1
• zebra-rpc: versions from 1.0.0-beta.45 up to (but not including) 6.0.2

Description

Zebra's JSON-RPC HTTP middleware treated a failure to read the incoming HTTP request body as an unrecoverable error, aborting the process rather than returning an error response. A client that disconnected after sending only part of a request body, for example, by resetting the TCP connection mid-transfer, was sufficient to trigger the crash. The vulnerability could be exploited only by authenticated RPC clients. Nodes running the shipped defaults, with RPC bound to localhost and cookie authentication on, were not vulnerable.

Impact

Denial of Service

• Attack Vector: Network, authenticated (requires a valid RPC cookie when cookie authentication is enabled).
• Effect: Immediate crash of the Zebra node.
• Scope: Any node whose RPC interface is reachable by a client with valid credentials, or any node with cookie authentication disabled and an exposed RPC interface.

Fixed Versions

This issue is fixed in Zebra 4.3.1 (crate zebra-rpc 6.0.2).

The fix propagates failures to read the HTTP request body as ordinary error responses, so Zebra now rejects truncated or interrupted requests rather than crashing.

Mitigation

Users should upgrade to Zebra 4.3.1 or later.

If an immediate upgrade is not possible, users should ensure their RPC port is not exposed to untrusted networks and that cookie authentication remains enabled (the default).

References

• Zebra 4.3.1 Release Announcement

Credits

Thanks to shieldedonly who discovered this issue and reported it via our coordinated disclosure process.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

A vulnerability in Zebra's JSON-RPC HTTP middleware allows an authenticated RPC client to cause a Zebra node to crash by disconnecting before the request body is fully received. The node treats the failure to read the HTTP request body as an unrecoverable error and aborts the process instead of returning an error response.

Severity

Moderate - This is a Denial of Service (DoS) that requires a client capable of passing Zebra's cookie authentication, which is enabled by default.

Affected Versions

• zebrad: versions from 2.2.0 up to (but not including) 4.3.1
• zebra-rpc: versions from 1.0.0-beta.45 up to (but not including) 6.0.2

Description

Zebra's JSON-RPC HTTP middleware treated a failure to read the incoming HTTP request body as an unrecoverable error, aborting the process rather than returning an error response. A client that disconnected after sending only part of a request body, for example, by resetting the TCP connection mid-transfer, was sufficient to trigger the crash. The vulnerability could be exploited only by authenticated RPC clients. Nodes running the shipped defaults, with RPC bound to localhost and cookie authentication on, were not vulnerable.

Impact

Denial of Service

• Attack Vector: Network, authenticated (requires a valid RPC cookie when cookie authentication is enabled).
• Effect: Immediate crash of the Zebra node.
• Scope: Any node whose RPC interface is reachable by a client with valid credentials, or any node with cookie authentication disabled and an exposed RPC interface.

Fixed Versions

This issue is fixed in Zebra 4.3.1 (crate zebra-rpc 6.0.2).

The fix propagates failures to read the HTTP request body as ordinary error responses, so Zebra now rejects truncated or interrupted requests rather than crashing.

Mitigation

Users should upgrade to Zebra 4.3.1 or later.

If an immediate upgrade is not possible, users should ensure their RPC port is not exposed to untrusted networks and that cookie authentication remains enabled (the default).

References

• Zebra 4.3.1 Release Announcement

Credits

Thanks to shieldedonly who discovered this issue and reported it via our coordinated disclosure process.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

A vulnerability in Zebra's JSON-RPC HTTP middleware allows an authenticated RPC client to cause a Zebra node to crash by disconnecting before the request body is fully received. The node treats the failure to read the HTTP request body as an unrecoverable error and aborts the process instead of returning an error response.

Severity

Moderate - This is a Denial of Service (DoS) that requires a client capable of passing Zebra's cookie authentication, which is enabled by default.

Affected Versions

• zebrad: versions from 2.2.0 up to (but not including) 4.3.1
• zebra-rpc: versions from 1.0.0-beta.45 up to (but not including) 6.0.2

Description

Zebra's JSON-RPC HTTP middleware treated a failure to read the incoming HTTP request body as an unrecoverable error, aborting the process rather than returning an error response. A client that disconnected after sending only part of a request body, for example, by resetting the TCP connection mid-transfer, was sufficient to trigger the crash. The vulnerability could be exploited only by authenticated RPC clients. Nodes running the shipped defaults, with RPC bound to localhost and cookie authentication on, were not vulnerable.

Impact

Denial of Service

• Attack Vector: Network, authenticated (requires a valid RPC cookie when cookie authentication is enabled).
• Effect: Immediate crash of the Zebra node.
• Scope: Any node whose RPC interface is reachable by a client with valid credentials, or any node with cookie authentication disabled and an exposed RPC interface.

Fixed Versions

This issue is fixed in Zebra 4.3.1 (crate zebra-rpc 6.0.2).

The fix propagates failures to read the HTTP request body as ordinary error responses, so Zebra now rejects truncated or interrupted requests rather than crashing.

Mitigation

Users should upgrade to Zebra 4.3.1 or later.

If an immediate upgrade is not possible, users should ensure their RPC port is not exposed to untrusted networks and that cookie authentication remains enabled (the default).

References

• Zebra 4.3.1 Release Announcement

Credits

Thanks to shieldedonly who discovered this issue and reported it via our coordinated disclosure process.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

A vulnerability in Zebra's JSON-RPC HTTP middleware allows an authenticated RPC client to cause a Zebra node to crash by disconnecting before the request body is fully received. The node treats the failure to read the HTTP request body as an unrecoverable error and aborts the process instead of returning an error response.

Severity

Moderate - This is a Denial of Service (DoS) that requires a client capable of passing Zebra's cookie authentication, which is enabled by default.

Affected Versions

• zebrad: versions from 2.2.0 up to (but not including) 4.3.1
• zebra-rpc: versions from 1.0.0-beta.45 up to (but not including) 6.0.2

Description

Zebra's JSON-RPC HTTP middleware treated a failure to read the incoming HTTP request body as an unrecoverable error, aborting the process rather than returning an error response. A client that disconnected after sending only part of a request body, for example, by resetting the TCP connection mid-transfer, was sufficient to trigger the crash. The vulnerability could be exploited only by authenticated RPC clients. Nodes running the shipped defaults, with RPC bound to localhost and cookie authentication on, were not vulnerable.

Impact

Denial of Service

• Attack Vector: Network, authenticated (requires a valid RPC cookie when cookie authentication is enabled).
• Effect: Immediate crash of the Zebra node.
• Scope: Any node whose RPC interface is reachable by a client with valid credentials, or any node with cookie authentication disabled and an exposed RPC interface.

Fixed Versions

This issue is fixed in Zebra 4.3.1 (crate zebra-rpc 6.0.2).

The fix propagates failures to read the HTTP request body as ordinary error responses, so Zebra now rejects truncated or interrupted requests rather than crashing.

Mitigation

Users should upgrade to Zebra 4.3.1 or later.

If an immediate upgrade is not possible, users should ensure their RPC port is not exposed to untrusted networks and that cookie authentication remains enabled (the default).

References

• Zebra 4.3.1 Release Announcement

Credits

Thanks to shieldedonly who discovered this issue and reported it via our coordinated disclosure process.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

A vulnerability in Zebra's JSON-RPC HTTP middleware allows an authenticated RPC client to cause a Zebra node to crash by disconnecting before the request body is fully received. The node treats the failure to read the HTTP request body as an unrecoverable error and aborts the process instead of returning an error response.

Severity

Moderate - This is a Denial of Service (DoS) that requires a client capable of passing Zebra's cookie authentication, which is enabled by default.

Affected Versions

• zebrad: versions from 2.2.0 up to (but not including) 4.3.1
• zebra-rpc: versions from 1.0.0-beta.45 up to (but not including) 6.0.2

Description

Zebra's JSON-RPC HTTP middleware treated a failure to read the incoming HTTP request body as an unrecoverable error, aborting the process rather than returning an error response. A client that disconnected after sending only part of a request body, for example, by resetting the TCP connection mid-transfer, was sufficient to trigger the crash. The vulnerability could be exploited only by authenticated RPC clients. Nodes running the shipped defaults, with RPC bound to localhost and cookie authentication on, were not vulnerable.

Impact

Denial of Service

• Attack Vector: Network, authenticated (requires a valid RPC cookie when cookie authentication is enabled).
• Effect: Immediate crash of the Zebra node.
• Scope: Any node whose RPC interface is reachable by a client with valid credentials, or any node with cookie authentication disabled and an exposed RPC interface.

Fixed Versions

This issue is fixed in Zebra 4.3.1 (crate zebra-rpc 6.0.2).

The fix propagates failures to read the HTTP request body as ordinary error responses, so Zebra now rejects truncated or interrupted requests rather than crashing.

Mitigation

Users should upgrade to Zebra 4.3.1 or later.

If an immediate upgrade is not possible, users should ensure their RPC port is not exposed to untrusted networks and that cookie authentication remains enabled (the default).

References

• Zebra 4.3.1 Release Announcement

Credits

Thanks to shieldedonly who discovered this issue and reported it via our coordinated disclosure process.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

A vulnerability in Zebra's JSON-RPC HTTP middleware allows an authenticated RPC client to cause a Zebra node to crash by disconnecting before the request body is fully received. The node treats the failure to read the HTTP request body as an unrecoverable error and aborts the process instead of returning an error response.

Severity

Moderate - This is a Denial of Service (DoS) that requires a client capable of passing Zebra's cookie authentication, which is enabled by default.

Affected Versions

• zebrad: versions from 2.2.0 up to (but not including) 4.3.1
• zebra-rpc: versions from 1.0.0-beta.45 up to (but not including) 6.0.2

Description

Zebra's JSON-RPC HTTP middleware treated a failure to read the incoming HTTP request body as an unrecoverable error, aborting the process rather than returning an error response. A client that disconnected after sending only part of a request body, for example, by resetting the TCP connection mid-transfer, was sufficient to trigger the crash. The vulnerability could be exploited only by authenticated RPC clients. Nodes running the shipped defaults, with RPC bound to localhost and cookie authentication on, were not vulnerable.

Impact

Denial of Service

• Attack Vector: Network, authenticated (requires a valid RPC cookie when cookie authentication is enabled).
• Effect: Immediate crash of the Zebra node.
• Scope: Any node whose RPC interface is reachable by a client with valid credentials, or any node with cookie authentication disabled and an exposed RPC interface.

Fixed Versions

This issue is fixed in Zebra 4.3.1 (crate zebra-rpc 6.0.2).

The fix propagates failures to read the HTTP request body as ordinary error responses, so Zebra now rejects truncated or interrupted requests rather than crashing.

Mitigation

Users should upgrade to Zebra 4.3.1 or later.

If an immediate upgrade is not possible, users should ensure their RPC port is not exposed to untrusted networks and that cookie authentication remains enabled (the default).

References

• Zebra 4.3.1 Release Announcement

Credits

Thanks to shieldedonly who discovered this issue and reported it via our coordinated disclosure process.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

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.

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. With enable_cookie_auth = false, any network client reaching the RPC port can trigger it.

Summary

The getblocktemplate RPC handler panics when parsing a LongPollId parameter that contains non-ASCII (multi-byte UTF-8) characters. The handler performs byte-index string slicing on the user-supplied string, which panics in Rust when a byte index falls within a multi-byte character boundary. Because Zebra's release profile sets panic = "abort", the panic terminates the entire node process.

Details

The getblocktemplate handler receives a user-supplied LongPollId string and slices it at fixed byte offsets to extract the encoded tip hash and tip height. When the string contains multi-byte UTF-8 characters, a byte-index slice can land in the middle of a character, causing Rust's str indexing to panic with "byte index is not a char boundary."

Under the panic = "abort" release profile, this panic terminates the entire zebrad process rather than just the RPC task.

Patches

zebra-rpc 8.0.0 and zebrad 4.5.0.

Replace byte-index string slicing with character-aware parsing or validate that the LongPollId string contains only ASCII characters before slicing.

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 validates LongPollId parameters are ASCII-only before forwarding.

Impact

A single authenticated RPC request terminates the zebrad process. Same impact profile as GHSA-c8w6-x74f-vmg3: repeatable on restart, affects mining pools and infrastructure that forward getblocktemplate calls.

Credit

Reported by @sangsoo-osec via a private GitHub Security Advisory submission.

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.