A falha do curl começa no upload: priorize o caminho realmente exposto
A correção do curl pede atenção a uploads HTTP/2, libcurl embutida e backports. A demonstração de laboratório não prova exploração disseminada.
O curl 8.23.0 corrige a CVE-2026-92392, um uso de memória após liberação que afeta curl e libcurl das versões 8.12.0 a 8.22.0.[6] O caminho descrito exige upload de um arquivo de aproximadamente 135 KB por HTTP/2 para um servidor controlado pelo atacante, com certificado aceito pelo cliente e suporte ao protocolo na compilação.[6] Não é uma exploração de um download comum.[6]
O que muda para quem desenvolve
O pesquisador demonstrou execução de código, mas a exploração depende de detalhes como versão, arquitetura, alocador, disposição de memória e sincronização das transferências.[6] O projeto classificou a falha como de gravidade alta, sem atribuir CVSS, e não havia ataques conhecidos relatados.[6]
A leitura operacional é priorizar o caminho que existe no produto. Se uma aplicação envia arquivos para destinos externos, essa integração merece uma análise diferente de um utilitário que não faz uploads. A mesma dependência pode ocupar posições de risco distintas conforme seu uso.
O outro cuidado é descobrir qual cópia da biblioteca realmente atende à requisição. Recomendo vincular o inventário ao processo ou à imagem implantada, em vez de aceitar a presença de um pacote atualizado no host como evidência suficiente para toda a aplicação.
Como aplicar
Liste os fluxos de envio de arquivos, seus destinos e a política de protocolo. Para cada um, registre o build carregado e a origem da correção. Além da versão 8.23.0, o relato aponta correções nas linhas 8.14.3, 8.16.2 e 8.20.2.[6] O Debian 13 recebeu backport no pacote 8.14.1-2+deb13u7, enquanto o Debian 12 não contém esse código vulnerável.[6]
Esses exemplos ajudam a evitar uma regra ingênua de comparar apenas o número principal. Exija evidência do pacote e da revisão usados na implantação. Depois da mudança, faça um upload funcional para um destino de teste controlado e confira o protocolo negociado e a versão em execução. Isso valida a integração corrigida, não reproduz a exploração.
Quando não for possível atualizar imediatamente, a mitigação recomendada é evitar HTTP/2.[6] Em aplicações com libcurl, a política precisa considerar também o reaproveitamento de conexões, porque solicitar HTTP/1.1 não garante que uma conexão existente de outro tipo nunca será reutilizada.[6]
Cuidados e limites
Compilações sem suporte a HTTP/2 não alcançam o caminho descrito.[6] O projeto avalia que uma tentativa real provavelmente causaria queda do processo, e a execução de código apresentada é uma demonstração altamente condicionada.[6]
A descoberta foi creditada a Luna, com Claude, da Anthropic, relacionada ao OSS Scanner.[6] Isso é um resultado concreto de pesquisa assistida por IA, não uma licença para ignorar as condições técnicas. Corrija a dependência com evidência de implantação e mantenha a avaliação de risco proporcional ao fluxo real.
Fonte
[6] Fonte: The Hacker News