Rajat Raghav

**Nome do Software Vulnerável e Versões Afetadas** Apache Traffic Server versões 9.0.0 through 9.2.14 Apache Traffic Server versões 10.0.0 through 10.1.3 **Description** Existe um problema relacionado à interpretação inconsistente de requisições HTTP, conhecido como HTTP Request/Response Smuggling. Isso ocorre devido ao parsing de quoted-strings em extensões chunked. **Recommendations** Atualizar o Apache Traffic Server versões 9.0.0 through 9.2.14 para a versão 9.2.15. Atualizar o Apache Traffic Server versões 10.0.0 through 10.1.3 para a versão 10.1.4.

**Nome do Software Vulnerável e Versões Afetadas** Versões do Pingora anteriores a 0.8.0 **Descrição** Um problema de smuggling de solicitações HTTP (CWE-444) existe no tratamento de atualizações de conexão HTTP/1.1 pelo Pingora. O problema ocorre quando o proxy lê uma solicitação com um cabeçalho Upgrade e encaminha os bytes restantes da conexão para um backend antes que o backend aceite a atualização. Isso permite que um atacante envie uma carga maliciosa após uma solicitação contendo um cabeçalho Upgrade, que o backend pode interpretar como um cabeçalho de solicitação subsequente, contornando controles de segurança. Isso pode levar ao contorno de controles ACL no nível de proxy e lógica do WAF, ao envenenamento de caches e conexões upstream, e à execução de ataques cross-user por meio do sequestro de sessões ou do smuggling de solicitações. A infraestrutura de CDN da Cloudflare não foi afetada. O componente vulnerável é o tratamento do cabeçalho `Upgrade` em solicitações HTTP. **Recomendações** Atualize para a versão 0.8.0 ou superior do Pingora. Como alternativa, retorne um erro para solicitações com o cabeçalho `Upgrade` presente na lógica do filtro de solicitações para interromper o processamento de bytes além do cabeçalho da solicitação e desativar o reuso de conexões downstream.

**Nome do Software Vulnerável e Versões Afetadas** Versões do Pingora anteriores a 0.8.0 **Descrição** Uma vulnerabilidade de Smuggling de Solicitações HTTP existe devido à análise inadequada de solicitações HTTP/1.0 e solicitações com Transfer-Encoding. O problema surge ao permitir que os corpos de solicitações HTTP/1.0 sejam delimitados por "close" e ao tratamento incorreto de múltiplos valores de Transfer-Encoding, o que pode dessincronizar a estruturação de solicitações entre o Pingora e os servidores de backend. Isso poderia permitir que atacantes contornassem listas de controle de acesso em nível de proxy e lógica de firewall de aplicação web, envenenem caches e conexões upstream, e realizassem ataques entre usuários por meio do sequestro de sessões ou do smuggling de solicitações. A infraestrutura CDN da Cloudflare não foi afetada. Os endpoints da API não são explicitamente mencionados. Os parâmetros ou variáveis vulneráveis não são explicitamente mencionados. As funções vulneráveis não são explicitamente mencionadas. **Recomendações** Atualize para a versão 0.8.0 do Pingora ou superior. Como medida alternativa, rejeite solicitações não HTTP/1.1, solicitações com Content-Length inválido, solicitações com múltiplos cabeçalhos Transfer-Encoding ou solicitações com um cabeçalho Transfer-Encoding que não seja exatamente "chunked".

**Nome do Software Vulnerável e Versões Afetadas** Versões do Pingora anteriores a 0.8.0 **Descrição** Existe um problema de envenenamento de cache na construção padrão da chave de cache do framework de proxy HTTP Pingora. A implementação padrão da chave de cache HTTP gera chaves utilizando apenas o caminho da URI, excluindo o cabeçalho Host, o que pode levar ao envenenamento de cache e à entrega de respostas de origem cruzada aos usuários. Isso poderia permitir que um atacante realize vazamento de dados entre inquilinos em implantações multi-inquilino ou sirva conteúdo malicioso a usuários legítimos ao envenenar entradas de cache compartilhadas. **Recomendações** Atualize para a versão 0.8.0 ou superior do Pingora, que remove a implementação insegura da chave de cache padrão. Os usuários devem implementar seu próprio callback que inclua fatores apropriados, como o cabeçalho Host e o esquema HTTP do peer upstream. Se não for possível atualizar, remova qualquer uso padrão de CacheKey e implemente uma solução personalizada que inclua o cabeçalho Host e o esquema HTTP do peer upstream.