1. Você executa ` zebrad` até e incluindo ` v 4.4.1 `. 2. O seu `zebrad.toml` define `rpc.listen_addr` para um endereço TCP (o servidor RPC está habilitado). 3. Um atacante pode autenticar o objetivo do RPC. Com o padrão `enable_cookie_auth = true`, isto requer que o atacante leia o arquivo `.cookie` (tipicamente acesso local). Com `enable_cookie_auth = false`, qualquer cliente de rede que alcança a porta RPC pode acioná- la. O gerenciador de RPC `z_listunifiedReceivers` entra em pânico ao processar um Endereço Unificado estruturalmente válido cujo receptor Sapling transporta 43 bytes que falham na validação criptográfica (`sapling_crypto::PaymentAddress::from_bytes` retorna `Nenhum` para pontos não-subgrupo Jubjub). O manipulador chama `. expect("usando dados já decodificados como válidos")` no resultado falível. Como o perfil de lançamento do Zebra define `panic = "abort"`, o pânico termina todo o processo do nó, não apenas a tarefa do RPC. ` zcash_ address::unified::Encoding::decode` valida apenas o envelope estrutural de um Endereço Unificado (F 4 Jumble, bech 32 m, ordenação de código de tipo, 43 - comprimento de byte para Sapling). Ele não valida que o `pk_d` incorporado é um ponto de subgrupo Jubjub válido ou que o diversificador produz uma pré- imagem válida `g_d`.

Em ` zebra- rpc/ src/ methods.rs: 2893 `, o manipulador chama `Adresse::try_from_sapling(network, data)`, que delega para `sapling_crypto::PaymentAdresse::from_bytes`. Quando `from_bytes` retorna `Nenhum` (mais aleatório 32 -byte strings falham na verificação do subgrupo, os incêndios `. expect()` e o processo aborta. A mesma caixa já lida corretamente com isso em `try_from_unified` em ` zebra-chain/src/primentitives/ address.rs: 99 - 110 `, que retorna `Err` quando `from_bytes` falha. O caminho de código vulnerável contorna esta rota validada. zebra- rpc 8.0.0 e zebrado 4.5.0.

Substituir `.expect()` por `.map_err(їe) ErroObjecto::owned((...)` para propagação de erro correta, ou rota através do caminho existente `try_from_unified` que já manipula corretamente este caso. - Desativar o servidor RPC removendo `rpc.listen_ addr` de `zebrad.toml`. - Garantir `enable_cookie_ auth = true` (o padrão) e restringir o acesso ao sistema de arquivos ao arquivo `.cookie`. - Colocar um proxy inverso em frente ao port RPC que rejeita chamadas `z_listunifiedreceivers` com parâmetros de endereço não confiados. Um único pedido de RCP autenticado termina o processo ` zebrad`. O ataque é repetible ao reiniciar (o mesmo pedido ativa o mesmo abortar), permitindo que um atacante mantenha o nó abaixado indefinidamente até que o pedido seja filtrado a montante. Os operadores que usam backends `lightwalletd`, indexadores Zaino ou infraestrutura de pool de mineração que encaminham chamadas para ` zebrad` podem ser expostos se o caminho de encaminhamento passar por `z_listunifiedreceivers`.

Reportado por `@ robustfengbin` através de uma submissão privada de aconselhamento de segurança do GitHub. Registro de aconselhamento: GHSA- c 8 w 6 - x 74 f- vmg 3. Não há nenhum identificador adicional listado.

Tempo: GitHub Advisory Database publicou este registro em 2026 - 07 - 02 T 19: 37: 58.000 Z e lista a sua última modificação como 2026 - 07 - 02 T 19: 37: 58.000 Z. Gravidade: MODERAR. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H.

Software afetado e informações de versão: caixas.io pacote zebra-rpc — ECOSISTEM: introduzido 0, corrigido 8.0.0. caixas.io pacote zebrad — ECOSISTEM: introduzido 0, corrigido 4.5.0. Classificação e evidência: identificadores de fraqueza CWE- 20, CWE- 248, CWE- 617, CWE- 754. O registro contém 4 suporte de referências nestes tipos: WEB, PACKAGE.