O curl 8.23.0, lançado em 14 de outubro de 2026, chegou após uma auditoria que revelou 24 vulnerabilidades de segurança no projeto. O número exige uma distinção: de acordo com a empresa AISLE, seis problemas já haviam recebido correções no curl 8.22.0 e outros 18 foram corrigidos na versão 8.23.0.
Para quem usa o curl ou a biblioteca libcurl em servidores, aplicativos e automações, a prioridade é conferir os avisos do fornecedor e instalar as correções apropriadas — não simplesmente comparar números de versão.
O que mudou na atualização do curl 8.23.0?
O curl é uma ferramenta de linha de comando para transferir dados por protocolos como HTTP e HTTPS. Sua biblioteca, a libcurl, também é incorporada a outros programas. Por isso, uma vulnerabilidade pode atingir tanto o comando instalado no computador quanto aplicações que usam a biblioteca.
O mantenedor Daniel Stenberg publicou detalhes da colaboração com a AISLE, que usou ferramentas de análise assistidas por inteligência artificial para investigar o código. Segundo o relato da AISLE, a auditoria produziu 24 CVEs distribuídas entre duas versões: seis em 8.22.0 e 18 em 8.23.0. Assim, dizer que todas as 24 foram corrigidas pela primeira vez no 8.23.0 seria impreciso.
Os problemas identificados abrangem diferentes áreas do software. O risco concreto depende do protocolo utilizado, da versão, das opções habilitadas e da forma como cada aplicação usa o curl.
Falha de alta gravidade envolve transferências HTTP/2
Entre os avisos publicados, a CVE-2026-92392 foi classificada pelo próprio projeto como de gravidade alta. Ela descreve uma condição de use-after-free, quando um programa volta a acessar uma área de memória já liberada, em circunstâncias relacionadas ao envio de dados por HTTP/2.
O aviso técnico aponta que, sob uma combinação específica e complexa de condições, o defeito pode representar risco de execução de código. Isso não significa que qualquer instalação do curl possa ser comprometida automaticamente nem que exista exploração ativa confirmada.
Para essa CVE, o projeto indica como afetadas versões upstream do curl de 8.12.0 a 8.22.0, com correção em 8.23.0 e também em versões de manutenção indicadas no próprio aviso. A lista de versões vulneráveis é específica desse problema e não deve ser aplicada indiscriminadamente às demais CVEs.
Quem precisa atualizar o curl e a libcurl?
O alerta interessa especialmente a administradores de servidores, equipes de desenvolvimento, responsáveis por contêineres e fornecedores de software que incorporam libcurl. Nem toda vulnerabilidade se aplica a todos os ambientes: é preciso cruzar os boletins com o pacote e a configuração efetivamente usados.
Em distribuições Linux, o pacote pode continuar exibindo um número de versão anterior ao 8.23.0 e ainda assim já conter a correção, graças ao backport — quando o fornecedor incorpora um patch de segurança a uma versão mantida por ele. Um aviso de segurança do Ubuntu ilustra esse processo.
Aplicações que distribuem sua própria libcurl precisam ser verificadas separadamente. Atualizar apenas o executável curl do sistema não garante que todos os programas tenham atualizado suas cópias da biblioteca.
Como verificar e aplicar a correção com segurança
Confira a versão instalada
Abra o terminal e execute curl --version. O resultado identifica a versão do executável e mostra informações sobre bibliotecas e protocolos disponíveis. Esse comando é um ponto de partida, não uma prova definitiva de vulnerabilidade.
Consulte o fornecedor do sistema
Procure o boletim de segurança de sua distribuição, plataforma ou fabricante e confirme o pacote corrigido. Prefira o gerenciador de pacotes e os canais oficiais do fornecedor; instalar manualmente uma versão upstream pode causar incompatibilidades ou deixar outros programas sem atualização.
Revise dependências e imagens de contêiner
Se você mantém uma aplicação, confira se ela usa a libcurl do sistema, uma cópia empacotada ou uma dependência estática. Atualize imagens-base e faça os testes de regressão antes de promover mudanças para produção.
Qual foi o papel da inteligência artificial na auditoria?
A AISLE informa que ferramentas de análise assistidas por IA ajudaram a identificar 18 das 24 vulnerabilidades reveladas no trabalho. Isso não equivale a dizer que uma IA encontrou, confirmou e corrigiu sozinha todos os problemas: os relatos descrevem colaboração com especialistas e validação pelo projeto curl.
O episódio se soma ao debate sobre testes de segurança com modelos de IA e experimentos de invasão conduzidos com IA. São contextos diferentes: neste caso, o foco é uma auditoria de código aberto e a divulgação coordenada de falhas.
Perguntas frequentes sobre o curl 8.23.0
O curl 8.23.0 corrigiu 24 vulnerabilidades sozinho?
Não. A auditoria divulgou 24 vulnerabilidades em duas versões: seis foram corrigidas no curl 8.22.0 e outras 18 no 8.23.0, segundo a AISLE.
Qual foi a falha mais grave do curl 8.23.0?
A CVE-2026-92392, classificada como alta pelo projeto curl, envolve uso de memória após sua liberação em determinadas transferências HTTP/2. A exploração depende de condições específicas.
Quem precisa atualizar o curl?
Administradores, desenvolvedores e fornecedores que utilizam versões ou bibliotecas afetadas devem verificar os avisos de segurança de seus sistemas e aplicar atualizações oficiais compatíveis.
Como saber se meu sistema está protegido?
O comando curl --version mostra a versão, mas não comprova sozinho a presença ou ausência de correções: distribuições Linux podem aplicar patches sem mudar para o número da versão upstream mais recente.
Foi uma inteligência artificial que corrigiu todas as falhas?
Não. A AISLE atribui a ferramentas assistidas por IA a identificação de 18 das 24 falhas, em um processo com revisão humana, validação técnica e correções conduzidas com o projeto curl.
O que fazer agora
Quem administra sistemas deve identificar onde curl e libcurl são utilizados, consultar os avisos oficiais para cada ambiente e aplicar os pacotes corrigidos. A atualização é importante, mas a decisão deve considerar o fornecedor, os patches retroportados e as condições específicas de cada CVE.
