Uma falha na forma como o curl trata uploads via HTTP/2 (segunda versão do protocolo de transferência de hipertexto) permite que um servidor malicioso que recebe o upload corrompa a memória do cliente. O pesquisador que reportou a falha transformou-a em execução de código na máquina que envia o arquivo.
O projeto curl corrigiu o problema em 14 de outubro, na curl 8.23.0. Assumir o controle de um cliente exige conhecimento exato da compilação e do layout de memória dele, e o próprio curl avalia que um ataque real tende a terminar em uma falha do programa, e não em controle do sistema.
A falha é um use-after-free (uso de memória após liberação) registrado sob o identificador CVE-2026-92392 (sigla de Common Vulnerabilities and Exposures, ou Vulnerabilidades e Exposições Comuns). Ela afeta o curl e a libcurl nas versões 8.12.0 a 8.22.0, tanto a ferramenta de linha de comando quanto a biblioteca que muitos outros programas usam para transferências. O curl classifica a falha como High (alta) em sua escala de quatro níveis, a primeira falha de gravidade alta desde a sobrecarga de heap no SOCKS5 (protocolo de proxy), em outubro de 2023. O projeto encurtou em duas semanas o ciclo de lançamento para entregar a correção.
O ataque parte do lado do servidor. O cliente precisa enviar um arquivo de cerca de 135 KB via HTTP/2 para um servidor controlado pelo atacante, e o certificado desse servidor precisa passar nas verificações do cliente. A libcurl negocia HTTP/2 por padrão em URLs https:// (versão segura do HTTP, ou HTTPS) quando o servidor oferece o recurso, e a biblioteca foi compilada com suporte a HTTP/2.
A falha está presente em todas as versões do curl desde a 8.12.0, lançada em fevereiro de 2025. Nenhuma fonte relata ataques que a utilizem. O relatório do pesquisador no HackerOne, com o script do servidor malicioso e um contêiner Docker descrito como capaz de reproduzir a execução de código, tornou-se público em 14 de outubro, junto com o comunicado de segurança.
O que instalar e o que fazer até lá
Atualize para a 8.23.0 ou aplique o commit de correção em uma compilação local. O aviso legível por máquina do curl também lista versões corrigidas em três ramos mais antigos. O projeto afirmou que lançará versões atualizadas do Rock-solid curl, sua linha de suporte de longo prazo (LTS, de long-term support) para clientes com contratos de suporte, em sincronia com a 8.23.0:
- curl e libcurl 8.12.0 a 8.22.0: atualizar para a 8.23.0
- Ramo 8.14.x: 8.14.3
- Ramo 8.16.x: 8.16.2
- Ramo 8.20.x: 8.20.2
- Debian 13 (trixie): 8.14.1-2+deb13u7 a DSA-6558-1 (Debian Security Advisory, ou aviso de segurança do Debian), conforme o rastreador do Debian. O Debian 12 (bookworm) não traz o código vulnerável.
A versão corrige 24 CVEs no total. As outras 23 são classificadas como Low (baixa).
Se ainda não for possível atualizar, a recomendação do curl é não usar HTTP/2. A opção --http1.1 pede à ferramenta o HTTP/1.1, e aplicações definem CURLOPT_HTTP_VERSION como CURL_HTTP_VERSION_1_1. A documentação do curl diz que essa configuração é um pedido, porque uma conexão existente em outra versão pode ser reutilizada.
O suporte a HTTP/2 na libcurl é uma opção de compilação. Uma compilação sem esse suporte não consegue negociar HTTP/2 e, portanto, não alcança o caminho de upload descrito no aviso.
Como um servidor hostil transforma o bug em execução de código
Daniel Stenberg, desenvolvedor principal do curl, explicou o bug em um texto publicado junto com a versão, e o relatório público detalha o caminho do código. O HTTP/2 transporta várias transferências por uma mesma conexão, e a libcurl acompanha cada transferência com um objeto que chama de easy handle (manipulador “easy”).
Durante um upload, o servidor trava a transferência ao definir a janela do HTTP/2 como zero, devolve parte da resposta e, em seguida, reinicia o fluxo (stream) mantendo a conexão aberta. O curl interpreta o reinício como motivo para tentar novamente.
Na limpeza, o curl primeiro informa à camada HTTP/2 que a transferência terminou e só depois descarrega o restante do upload ainda não enviado na mesma conexão. Sem nenhuma transferência registrada, esses bytes que sobraram são lidos como uma nova requisição. Os padrões de linha que o pesquisador inclui no arquivo enviado fazem com que pareçam linhas de requisição. Quando isso acontece, abre-se um novo fluxo que armazena um ponteiro para o easy handle.
A nova tentativa é concluída em uma nova conexão HTTP/1.1, e a aplicação libera o handle. A conexão antiga ainda guarda o ponteiro e o usa quando o servidor envia um quadro (frame) naquele fluxo, o que pode acontecer enquanto o programa está sendo encerrado.
No exploit do pesquisador, os dados enviados pelo servidor caem na memória que o handle liberado usava. Uma requisição enviada vaza endereços locais, que o servidor precisa para contornar a aleatorização do layout do espaço de endereços (ASLR, na sigla em inglês). Um ponteiro de função nessa memória é sobrescrito com bytes enviados pelo servidor, e o curl então o chama.
A execução de código exige que o atacante conheça a versão exata do curl, a arquitetura, o alocador da biblioteca C padrão (libc) e o layout do heap do alvo. Também é preciso manter duas transferências paralelas no tempo certo e encaixar a carga útil em cerca de 23 bytes, segundo o aviso do curl. “O resultado mais provável de uma tentativa de ataque é apenas uma falha”, escreveu Stenberg, ao avaliar que a chance de sucesso é pequena. Por isso o curl classificou a falha como High, e não como Critical.
O curl usa quatro níveis de gravidade e não publica uma pontuação CVSS (Sistema de Pontuação de Vulnerabilidades Comuns). O National Vulnerability Database não havia analisado o registro até 14 de outubro.
A correção é uma reordenação de seis linhas no arquivo lib/multi.c, feita por Stefan Eissing. A camada HTTP/2 agora abre mão de suas referências ao handle depois que os dados de upload que sobraram foram descarregados, e não antes.
O relatório chegou ao curl em 15 de setembro pelo HackerOne, e a equipe de segurança confirmou o problema em poucas horas, segundo Stenberg. Em 7 de outubro, o projeto anunciou antecipadamente uma correção de gravidade alta para a próxima versão, reduzindo o ciclo de oito para seis semanas.
O curl credita a descoberta a “Luna with Claude, Anthropic”. Stenberg identifica o pesquisador como Luna Tong, da Anthropic, afirma que a descoberta veio pelo novo OSS Scanner da empresa e presume que modelos de IA (inteligência artificial) da companhia estiveram envolvidos.
A Anthropic lançou o OSS Scanner em 8 de outubro como um serviço opcional que analisa, com seus modelos, projetos de código aberto inscritos e envia os resultados por e-mail sem revisão humana, cada relatório acompanhado de um reprodutor e, quando disponível, de um patch candidato. O relatório do curl chegou três semanas antes desse lançamento público. O post de lançamento da Anthropic citou Stenberg dizendo que o scanner encontrou “uma das piores vulnerabilidades do curl relatadas nos últimos anos”, sem nomeá-la.
O mesmo mantenedor escreveu em julho de 2025 que cerca de um quinto das submissões de segurança ao curl naquele ano foram o que ele chamou de “AI slop” (algo como “lixo de IA”, ou seja, conteúdo de baixa qualidade gerado por IA), e que apenas cerca de uma em cada vinte se provou genuína.
O curl vem reduzindo há anos o número de ponteiros internos para handles, em favor de identificadores que são buscados quando necessário, escreveu Stenberg. Essa mudança, porém, não é garantia contra outro use-after-free. O curl classifica o bug como um erro que uma linguagem com segurança de memória provavelmente teria evitado, mas o projeto não pretende reescrever o curl em uma linguagem assim.
