Uma falha na forma como o curl lida com envios por HTTP/2 permite que um servidor malicioso corrompa a memória do cliente que está enviando um arquivo. O pesquisador que relatou o problema transformou a falha em execução de código na máquina que faz o envio.
O projeto curl corrigiu o problema em 14 de outubro, com o lançamento do curl 8.23.0. Para assumir o controle de um cliente, é necessário conhecer com precisão a compilação e a disposição da memória do alvo. Ainda assim, o projeto estima que um ataque real provavelmente provocaria apenas uma falha do programa.
A falha, classificada como use-after-free e identificada como
CVE-2026-92392
, afeta o curl e o libcurl das versões 8.12.0 a 8.22.0. O problema está tanto na ferramenta de linha de comando quanto na biblioteca usada por muitos outros programas para transferências. O curl a classifica como de gravidade Alta, em sua escala de quatro níveis. É a primeira falha de gravidade Alta desde o heap overflow no SOCKS5, em outubro de 2023. O projeto encurtou o ciclo de lançamento em duas semanas para publicar a correção.
O ataque parte do servidor. O cliente precisa enviar um arquivo de aproximadamente 135 KB por HTTP/2 para um servidor controlado pelo invasor, e o certificado desse servidor deve ser aprovado pelas verificações do cliente. Por padrão, o libcurl negocia HTTP/2 em endereços https:// quando o servidor oferece suporte ao protocolo, desde que a biblioteca tenha sido compilada com suporte a HTTP/2.
A falha está presente em todas as versões do curl lançadas desde a 8.12.0, em fevereiro de 2025. Não há relatos públicos de ataques que explorem o problema. O relatório do pesquisador no HackerOne, que inclui o script do servidor malicioso e um contêiner Docker descrito como capaz de reproduzir a execução de código, foi publicado em 14 de outubro, junto com o comunicado de segurança.
O que instalar e como se proteger até lá
Atualize para a versão 8.23.0 ou aplique o patch à compilação local. O comunicado do curl em formato legível por máquina também lista versões corrigidas em três ramos mais antigos. O projeto informou que lançaria versões atualizadas do Rock-solid curl, sua linha de suporte de longo prazo para clientes com contratos de suporte, ao mesmo tempo que a versão 8.23.0:
- curl e libcurl das versões 8.12.0 a 8.22.0: atualize para a 8.23.0;
- ramo 8.14.x: versão 8.14.3;
- ramo 8.16.x: versão 8.16.2;
- ramo 8.20.x: versão 8.20.2;
- Debian 13 (trixie): versão 8.14.1-2+deb13u7 ou posterior, segundo o rastreador do Debian, por meio do DSA-6558-1. O Debian 12 (bookworm) não inclui o código vulnerável.
O lançamento corrige 24 CVEs no total. As outras 23 foram classificadas como de gravidade Baixa.
Se não for possível atualizar imediatamente, a recomendação do curl é evitar o HTTP/2. A opção --http1.1 solicita que a ferramenta use HTTP/1.1. Em aplicações, é preciso definir CURLOPT_HTTP_VERSION como CURL_HTTP_VERSION_1_1. A documentação do curl ressalta que essa configuração é uma solicitação, pois uma conexão já aberta pode ser reutilizada mesmo que use outra versão do protocolo.
O suporte a HTTP/2 no libcurl é uma opção de compilação. Uma versão compilada sem esse suporte não pode negociar HTTP/2 e, portanto, não chega ao caminho de envio descrito no comunicado.
Como um servidor hostil transforma a falha em execução de código
Daniel Stenberg, principal desenvolvedor do curl, explicou o problema em uma publicação feita junto com o lançamento. O relatório público detalha o caminho percorrido pelo código. O HTTP/2 permite várias transferências em uma única conexão, e o libcurl acompanha cada transferência por meio de um objeto chamado easy handle.
Durante um envio, o servidor interrompe temporariamente a transferência ao definir como zero a janela do HTTP/2, retornar parte da resposta e, em seguida, reiniciar o fluxo sem encerrar a conexão. 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, depois, envia pela mesma conexão os dados restantes do arquivo que ainda não tinham sido transmitidos. Como não há uma transferência registrada, esses dados são interpretados como uma nova solicitação. O padrão de linhas incluído pelo pesquisador no arquivo enviado faz com que os dados pareçam linhas de solicitação. Quando isso ocorre, um novo fluxo é aberto e armazena um ponteiro para o easy handle.
A nova tentativa termina em uma conexão HTTP/1.1, e a aplicação libera o easy handle. A conexão antiga, porém, ainda mantém o ponteiro e o utiliza quando o servidor envia um quadro nesse fluxo, o que pode acontecer enquanto o programa está sendo encerrado.
No exploit do pesquisador, os dados enviados pelo servidor ocupam a memória antes usada pelo identificador já liberado. Uma solicitação enviada pelo cliente revela endereços locais, necessários para que o servidor contorne a randomização do espaço de endereçamento (ASLR). Em seguida, um ponteiro de função nessa memória é sobrescrito com bytes enviados pelo servidor, e o curl acaba chamando a função apontada.
Segundo o comunicado do curl, para executar código o invasor precisa conhecer a versão exata do curl no alvo, a arquitetura, o alocador de memória da libc e a disposição do heap. Também precisa sincronizar duas transferências paralelas e fazer o payload caber em cerca de 23 bytes. “O resultado mais provável de uma tentativa de ataque é simplesmente uma falha do programa”, escreveu Stenberg, que considera pequena a chance de sucesso. Por isso, o curl classificou a falha como de gravidade Alta, e não Crítica.
O curl usa quatro níveis de gravidade e não publica uma pontuação CVSS. Em 14 de outubro, o National Vulnerability Database dos Estados Unidos ainda não havia analisado o registro.
A correção consiste em reorganizar seis linhas no arquivo lib/multi.c, em uma alteração feita por Stefan Eissing. Agora, a camada HTTP/2 descarta as referências ao easy handle somente depois de enviar os dados restantes do arquivo, e não antes.
Segundo Stenberg, o relatório chegou ao curl em 15 de setembro, pelo HackerOne, e a equipe de segurança confirmou o problema em poucas horas. Em 7 de outubro, o projeto anunciou antecipadamente uma correção de gravidade Alta para o lançamento seguinte e reduziu o ciclo de oito para seis semanas.
O curl atribui a descoberta a “Luna com Claude, da Anthropic”. Stenberg identifica a pesquisadora como Luna Tong, da Anthropic, diz que a falha foi encontrada por meio do novo serviço OSS Scanner da empresa e supõe que seus modelos de IA tenham participado da análise.
A Anthropic abriu o OSS Scanner em 8 de outubro como um serviço opcional que examina projetos de código aberto inscritos com seus modelos e envia os resultados por e-mail, sem revisão humana. Cada relatório inclui um código de reprodução e, quando disponível, uma sugestão de patch. O relatório sobre o curl chegou três semanas antes do lançamento público do serviço. Na publicação de lançamento, a Anthropic citou Stenberg dizendo que o scanner havia encontrado “uma das piores vulnerabilidades do curl relatadas nos últimos anos”, sem identificar o problema.
Em julho de 2025, o mesmo responsável pelo projeto escreveu que cerca de um quinto dos relatos de segurança recebidos pelo curl naquele ano era o que chamou de conteúdo de baixa qualidade gerado por IA. Segundo ele, apenas cerca de um em cada 20 relatos se mostrou legítimo.
O curl vem reduzindo há vários anos o número de ponteiros internos para identificadores, substituindo-os por identificadores que são consultados quando necessário, escreveu Stenberg. Essa mudança, porém, não garante que outra falha de use-after-free não ocorra. O curl descreve o problema como um erro que provavelmente teria sido evitado com uma linguagem segura para a memória, mas não planeja reescrever o projeto em outra linguagem.
Publicidade
Vibecoding cria 10x mais sistemas, 20x mais vulneráveis. E quem ganha com isso é a galera do hacking ético e pentest. Quer ser pago para invadir sistemas? Então você tem que aprender com a Solyd que são os melhores do Brasil. Saiba mais...