Fedify anteriormente endereçado SSRF/acesso à rede interna no GHSA-p 9 cg- vqcc- grcx adicionando validação pública de URL antes de executar o documento e a busca de mídia. No entanto, o IPv atual 4 A lógica de validação parece incompleta. A proteção `validatePublicUrl()` depende de ` isValidPublicIPv 4 Endereço()` para rejeitar IPv não público 4 destinos. A função bloqueia intervalos privados e locais comuns, como ` 10.0.0.0 / 8 `, ` 127.0.0.0 / 8 `, ` 169.254.0.0 / 16 `, ` 172.16.0.0 / 12 `, e ` 192.168.0.0 / 16 `, mas ainda trata vários usos especiais, reservados, multicast, benchmarking e NAT IPv de nível transportador 4 gamas como destinos públicos válidos. Como esta validação é usada como defesa SSRF antes de sair, esta parece ser uma classe de mitigação ou de bypass incompleta para o número anterior da SSRF. Testei isso contra o código do repositório atual na versão inédita 2.3.0. Eu usei `>= 0.11.2, <= 2.2.3 ` como o intervalo afetado suspeito porque 0.11.2 está listado como uma versão correcionada para o GHSA- p 9 cg- vqcc- grcx, e este relatório diz respeito à lógica de validação pós-fixo. Os mantenedores podem ajustar o intervalo exato afetado.
### Por que isto não é uma duplicação do GHSA-p 9 cg- vqcc- grcx GHSA- p 9 cg- vqcc- grcx cobriu o comportamento original onde Fedify obtém objetos, atividades, documentos e URLs de mídia do ActivityPub recuperados sem garantir que o destino resolvido fosse público. Este relatório é sobre a lógica de validação pós-fixo. A mitigação atual agora executa a validação pública de URL/IP, mas o IPv 4 classificação incompleta e ainda trata várias gamas de uso especial como públicas. Portanto, este é um possível correção/ superação incompleta da mitigação anterior da SSRF, em vez de um novo relatório do problema original. O comportamento afetado parece existir no caminho do código correto/ corrente, não apenas nas versões listadas como vulneráveis no aviso original.
`pacotes/vocab-runtime/src/url.ts`. IPv atual 4 Lógica de validação: ```ts a função de exportação éValidPublicIPv 4 Endereço(endereço: string): boolean { const parts = address.split("); const first = parseInt( parts[ 0 ]); se (primeiro === 0 Primeiro 10 Primeiro 127 ) retorna false; const second = parseInt(parts[ 1 ]); se (primeiro === 169 && segundo === 254 ) retorna false; se (primeiro === 172 && segundo >= 16 && segundo <= 31 ) retorna false; se (primeiro === 192 && segundo === 168 ) devolver falso; devolver verdadeiro; } ``` O ponto importante é que o bypass existe na lógica de mitigação em si: a função responsável por decidir se um destino é público retorna verdadeiro para os intervalos de endereços que não são destinações públicas de internet globalmente rotuláveis. ### Prova de Conceito. Reproduzi o IPv 4 comportamento de validação usando a mesma lógica:.
```ts function isValidPublicIPv 4 Endereço(endereço) { const parts = address.split(").; const first = parseInt(parts[ 0 ], 10 ); se (primeiro) 0 Primeiro 10 Primeiro 127 ) retornar falso; const second = parseInt(parts[ 1 ], 10 ); se (primeiro) 169 && segundo === 254 ) retorna false; se (primeiro === 172 && segundo >= 16 && segundo <= 31 ) retorna false; se (primeiro === 192 && segundo === 168 ) retornar falso; Testes const = [ " 8.8.8.8 ", " 127.0.0.1 ", " 10.0.0.1 ", " 192.168.1.1 ", " 169.254.169.254 ", " 100.64.0.1 ", " 198.18.0.1 ", " 224.0.0.1 ", " 240.0.0.1 ", " 192.0.0.1 ", " 192.0.2.1 ", " 198.51.100.1 ", " 203.0.113.1 " ]; para (const ip of tests) { console.log(ip + " => " + isValidPublicIPv 4 Endereço(ip)); } ```.
``` 8.8.8.8 => Verdadeiro 127.0.0.1 => falso 10.0.0.1 => falso 192.168.1.1 => falso 169.254.169.254 => falso 100.64.0.1 => Verdadeiro 198.18.0.1 => Verdadeiro 224.0.0.1 => Verdadeiro 240.0.0.1 => Verdadeiro 192.0.0.1 => Verdadeiro 192.0.2.1 => Verdadeiro 198.51.100.1 => Verdadeiro 203.0.113.1 => verdadeiro ``` O validador bloqueia corretamente alguns intervalos privados e locais comuns, mas incorretamente permite vários intervalos de uso especial. ### Exemplos de intervalos incorretamente permitidos. Exemplos importantes incluem: ``` 100.64.0.0 / 10 NAT de grau transportador 198.18.0.0 / 15 Benchmarking / redes internas de testes 224.0.0.0 / 4 Multicast 240.0.0.0 / 4 Reservado 192.0.0.0 / 24 As atribuições do protocolo IETF ```.
Exemplos adicionais de correção. ``` 192.0.2.0 / 24 Gama de documentação 198.51.100.0 / 24 Gama de documentação 203.0.113.0 / 24 Gama de documentação ``` Qualquer recurso Fedify que aceite ou processe objetos remotos do ActivityPub, atividade, documento ou URLs de mídia e que se baseie em validarPublicUrl() como um limite de proteção SSRF pode permitir incorretamente solicitações de saída para IPv de uso especial 4 destinos que não devem ser tratados como recursos públicos da internet. Isto pode permitir que um objeto ActivityPub controlado pelo atacante ou URL de mídia faça com que um servidor Fedify inicie solicitações para intervalos de rede não públicos ou especiais, dependendo do ambiente de implantação e do roteamento da rede. Isto é melhor entendido como uma classe de correção/bypass incompleta para o aconselhamento anterior do SSRF/interna-rede-acesso GHSA-p 9 CG- vqcc- grcx.
Evite usar uma pequena lista de negação manual para validação pública de IP. Em vez disso, validar que o endereço resolvido é globalmente rotável/ público. No mínimo, IPv 4 a validação deve rejeitar todas as gamas de uso especial relevantes, incluindo: ``` 0.0.0.0 / 8 10.0.0.0 / 8 100.64.0.0 / 10 127.0.0.0 / 8 169.254.0.0 / 16 172.16.0.0 / 12 192.0.0.0 / 24 192.0.2.0 / 24 192.168.0.0 / 16 198.18.0.0 / 15 198.51.100.0 / 24 203.0.113.0 / 24 224.0.0.0 / 4 240.0.0.0 / 4 ``` Uma correção de longo prazo mais segura seria usar uma biblioteca de classificação de endereços IP mantida que suporta explicitamente a validação IP pública/global sensível à segurança.
```ts a função de exportação éValidPublicIPv 4 Endereço(endereço: string): boolean { const parts = address.split(".").map((part) => parseInt(part, 10 )); if ( partes. comprimento! == 4 Parte de parte.some((parte) => Number.isNaN(parte)Parte de parte 255 ) ) { retorna false; } const [a, b] = partes. se (a) 0 ) retornar falso; se (a === 10 ) retornar falso; se (a === 100 & & b >= 64 & & b = 16 & & b = 224 ) retornar falso; ## Nota de Classificação de Aconselhamento. Entendo que isto possa ser classificado como um novo aviso ou como uma correção atual/incompleta para o GHSA-p 9 CG- vqcc- grcx. Como o problema parece afetar a lógica de validação adicionada após a correção original da SSRF, e como o código afetado faz parte do limite de segurança atual para a busca de URLs, eu queria reportá- lo em privado para revisão do mantenedor.
Este relatório não tenta acessar qualquer serviço de rede interna real. A prova foca na decisão de validação em si mesma: IPv múltiplo não público ou de uso especial 4 as gamas são aceitas como públicas pela lógica de proteção atual da SSRF. Reportado por Chaitanya Garware. Registro de aconselhamento: GHSA-xw 9 q-. 2 mv 6 - 9 fr 8. Identificadores relacionados: CVE- 2026 - 50131. Tempo: GitHub Advisory Database publicou este registro em 2026 - 07 - 14 T 18: 15: 25.000 Z e lista a sua última modificação como 2026 - 07 - 14 T 18: 15: 25.000 Z.
Severidade: ALTAMENTE. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L. Software afetado e informações de versão: pacote npm @fedify/fedify — ECOSYSTEM: introduzido 0.11.2, corrigido 1.9.12. pacote npm @fedify/fedify — ECOSISTEM: introduzido 1.10.0, corrigido 1.10.11. pacote npm @fedify/fedify — ECOSISTEM: introduzido 2.0.0, corrigido 2.0.19. pacote npm @fedify/fedify — ECOSISTEM: introduzido 2.1.0, corrigido 2.1.15. pacote npm @fedify/fedify — ECOSISTEM: introduzido 2.2.0, corrigido 2.2.4. pacote npm @fedify/vocab- runtime — ECOSISTEM: introduzido 0, corrigido 2.0.19. pacote npm @fedify/vocab- runtime — ECOSISTEM: introduzido 2.1.0, corrigido 2.1.15. pacote npm @fedify/vocab- runtime — ECOSISTEM: introduzido 2.2.0, corrigido 2.2.4. Classificação e evidência: identificadores de fraqueza CWE- 1286, CWE- 1389, CWE- 918. O registro contém 3 suporte de referências nestes tipos: WEB, AVISO, EMBALAGAMENTO.