GHSA-c8w6-x74f-vmg3: zebrad vulnerable to full node denial of service via crafted Sapling receiver in z_listunifiedreceivers

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