O Mythos disse que já não havia nada no curl. Uma startup encontrou seis CVE
By Surya Pratap
24 de setembro de 2026
10 min read
AI & Technology
24 de setembro de 2026
10 min read
Zero, e depois vinte e noveHover to exploreA 24 de agosto, Daniel Stenberg, responsável pelo curl, publicou duas linhas de estado. O Mythos, da Anthropic, «diz que não consegue encontrar mais nada». O Codex Security, da OpenAI, «mostra uma lista vazia». No dia seguinte publicou um marcador: Mythos: 0 / Aisle: 29.
Seis desses vinte e nove relatórios tornaram-se CVE e foram corrigidos no curl 8.22.0, lançado a 2 de setembro. Quase toda a cobertura contou alguma versão de startup vence a OpenAI e a Anthropic. É verdade, até certo ponto. É também a lição menos útil a tirar deste episódio.
Os números deste artigo vêm do relato da AISLE sobre as descobertas de agosto (2 de setembro de 2026), da tabela de vulnerabilidades do próprio curl, da análise de Daniel Stenberg à passagem do Mythos (11 de maio de 2026) e da reportagem da ZDNET (4 de setembro de 2026). A AISLE é um fornecedor a descrever o próprio resultado; os avisos do curl são a verificação independente. A leitura a partir da secção 3 é minha.
A cronologia é curta o suficiente para a contar por inteiro.
A Anthropic e a Alpha-Omega correram o Mythos sobre o código. Declarou cinco «vulnerabilidades de segurança confirmadas». A equipa de segurança do curl reviu-as e ficou com uma, de gravidade baixa. Três eram falsos positivos que descreviam comportamento documentado da API, uma era «apenas um bug» e da análise saíram cerca de vinte outros bugs sem impacto de segurança. O veredicto de Stenberg: o entusiasmo à volta do modelo era «sobretudo marketing», e o Mythos talvez fosse «um pouco melhor» do que ferramentas anteriores, não espetacularmente melhor.
O Mythos não encontra mais nada. Codex Security: lista vazia. A ZDNET acrescenta que o ZeroPath, outro scanner com IA, também não tinha encontrado nada de novo.
A 28 de agosto, a contagem de CVE pendentes do curl tinha passado de três para dez, seis deles da AISLE.
A tabela do curl enumera os seis: um use-after-free no fornecedor OpenSSL, um contorno do pinning no OpenSSL, reutilização de ligações com o repositório nativo de CA, um contorno do atributo secure dos cookies com um carácter de tabulação, um acerto na cache de CA do wolfSSL que sobrepõe um callback e um cookie de domínio sobre um sufixo público. Os seis são de gravidade baixa. Alguns vêm de longe: o contorno do pinning afeta todas as versões desde a 7.45.0.
A AISLE afirma ainda que lhe foram atribuídos seis CVE na versão de junho, a 8.21.0, incluindo um que descreve como a vulnerabilidade mais antiga alguma vez reportada no curl, introduzida em março de 2001. Não consegui confirmar essa atribuição nas páginas do próprio curl, por isso deixo-a fora do argumento.
Greg Kroah-Hartman, responsável pela versão estável do kernel Linux, acrescentou a frase que transformou isto em mais do que uma história sobre o curl: «Estou a ver o mesmo no Linux. Não faço ideia do que a Aisle está a fazer de diferente, mas uau…»
Estas são as duas passagens pelo curl com números publicados suficientes para comparar:
Não é a mesma medida. As cinco do Mythos já vinham rotuladas como vulnerabilidades confirmadas, enquanto os 29 da AISLE eram relatórios, e alguns dos outros 23 podem ter sido bugs legítimos e não ruído. Mas a ideia geral resiste à ressalva: a AISLE não ganhou em precisão. Os dois sistemas puseram diante do responsável cerca de quatro relatórios por confirmar por cada um que se tornou uma descoberta real.
A diferença não foi a AISLE acertar mais vezes. Foi a AISLE continuar a procurar quando as outras ferramentas já tinham parado.
Isso muda o assunto da história. Um modelo de ponta que corre, relata o que encontrou e depois diz que não há mais nada está a dizer-te onde terminou a sua pesquisa. O resultado da AISLE diz que os bugs do curl não terminavam aí. A capacidade que contou foi a cobertura, não o juízo sobre cada descoberta isolada.
Esta é a parte que te diz respeito, mesmo que nunca toques no curl.
Quando um scanner diz que não encontrou nada, ficas a saber o que essa ferramenta conseguiu ver a partir do sítio onde olhou. Não ficas a saber que o código está limpo. Sempre foi assim com os analisadores estáticos e os fuzzers, e é precisamente por isso que os engenheiros de segurança usam vários. O risco novo é que os scanners com IA explicam os resultados com fluência, e «analisei o código e não encontrei mais vulnerabilidades» soa a conclusão, não a limite de cobertura.
Duas formas de ler o mesmo zero
Lido como veredicto: o código não tem mais problemas deste tipo. Pode ir para produção.
Lido como limite: esta ferramenta, com este prompt, este orçamento de contexto e esta estratégia de pesquisa, deixou de produzir resultados. Outra com uma estratégia diferente talvez não.
O curl em agosto é um caso limpo em que a segunda leitura era a correta, num dos códigos em C mais sujeitos a fuzzing e mais auditados que existem.
Se um projeto maduro com um processo de segurança a tempo inteiro pode ter seis CVE reais escondidos atrás de duas listas vazias, um SaaS com doze meses que correu uma análise com IA antes da auditoria SOC 2 não provou grande coisa.
Nenhuma das publicações da AISLE descreve a arquitetura, por isso qualquer pormenor sobre o funcionamento seria especulação, e não vou oferecê-la. Há duas coisas registadas, e chegam.
A primeira é a formulação da própria AISLE: «A capacidade em cibersegurança é irregular: em tarefas de segurança bem definidas, modelos mais pequenos podem superar LLM muito maiores e mais caros.» Bate certo com o que vemos ao construir agentes de nicho. Um modelo generalista está afinado para ser razoavelmente bom em tudo. Um sistema construído para uma única tarefa pode gastar todo o orçamento no espaço de pesquisa dessa tarefa — que subsistemas, que configurações, que interações entre backends TLS e reutilização de ligações —, e as seis descobertas de agosto vivem exatamente nesse tipo de canto.
A segunda é o que o responsável notou. Os elogios de Stenberg não eram sobre capacidade bruta. Disse que a AISLE «investe verdadeiro tempo de engenharia para garantir que recebemos resultados cuidados e de topo». Jim Fuller, da Red Hat, disse algo semelhante: «trabalhou mais do que limitar-se a correr um scanner».
Juntando as duas coisas, o produto fica claro:
Não é um modelo melhor. É uma estratégia de pesquisa apontada a um único domínio, mais uma curadoria de nível humano antes de qualquer coisa chegar a quem tem de agir. O Mythos e o Codex Security são ferramentas generalistas ao alcance de todos. A AISLE é um sistema que alguém construiu para este trabalho e que esteve disposto a manter a correr depois de o terreno óbvio estar coberto.
Este episódio é provavelmente a prova pública mais clara até agora numa discussão que os fundadores têm vezes sem conta com investidores: o que impede o laboratório de fazer isto?
A ferramenta do laboratório para onde é generalista. O Mythos e o Codex Security foram feitos para funcionar em qualquer repositório. É essa amplitude que explica terem sido os primeiros a desistir do curl. A tua cunha é a profundidade que eles não conseguem justificar construir para um único vertical.
Vende resultados aceites, não produção em bruto. Ao curl não interessavam 29 relatórios. Interessavam seis CVE e o tempo do responsável que custou lá chegar. Se o teu produto gera descobertas, rascunhos ou leads, o número que o teu cliente sente é o que sobrevive à revisão dele, por hora do tempo dele.
A curadoria é produto, não custo indireto. A mesma taxa de acerto de 20% é uma dádiva quando alguém a verificou antes e um custo quando ninguém o fez. Stenberg chama ao momento atual dos relatórios de segurança com IA uma «era do caos de alta qualidade». Um produto que absorve esse caos vale mais do que um que o reencaminha.
Escolhe uma verdade de referência avaliada por outra pessoa. A afirmação da AISLE é credível porque foram os responsáveis do curl, e não a AISLE, que decidiram o que contava. Encontra o equivalente no teu domínio — um auditor, um regulador, um pull request integrado — e presta contas perante isso, não perante o teu próprio painel.
A metade desconfortável da mesma lição: se o teu produto é uma camada fina que chama uma vez um modelo de ponta e formata a resposta, é assim que o teu concorrente se parece.
Quatro mudanças, todas baratas:
Duas ferramentas generalistas de ponta partilham muitas vezes os mesmos pontos cegos. Junta uma delas a um analisador estático tradicional, a um fuzzer sobre os teus parsers ou a uma ferramenta especializada. É a diversidade de método que encontra a segunda camada.
Anota a ferramenta, a versão, os caminhos e a data. Um resultado vazio sem âmbito acaba citado num questionário de segurança como prova de algo que nunca mediu.
Com uma descoberta real em cada cinco, uma análise que devolve quarenta itens é uma semana de engenharia. Decide quem revê e com que rapidez antes de ligar a ferramenta, ou os relatórios ficam a apodrecer.
Quatro das seis descobertas de agosto no curl estão no comportamento dos backends TLS e as outras duas em casos-limite da análise de cookies: interações de configuração, não o caminho óbvio do pedido. No teu produto, o equivalente costuma ser os casos-limite de autenticação, as fronteiras entre clientes num sistema multi-tenant e tudo o que guarda credenciais em cache.
A AISLE é a fonte de quase toda a história. A cronologia, os 29 e o enquadramento vêm da publicação da própria AISLE. A tabela do curl confirma de forma independente os seis CVE e a sua gravidade; nada de independente confirma quanto processamento, tempo ou esforço humano foi preciso para os produzir.
A comparação não é controlada. O Mythos correu em maio e a AISLE no final de agosto, sobre um código que mudou entretanto e que já tinha absorvido as descobertas do Mythos. Isso torna o resultado da AISLE, quando muito, mais difícil e não mais fácil, mas continua a não ser um benchmark.
Os seis são de gravidade baixa. É o habitual no curl, onde raramente resta outra coisa para encontrar, mas significa que este episódio demonstra cobertura, não a capacidade de encontrar falhas críticas que outros deixaram escapar.
A comparação entre 20% e 21% é aproximada. Os dois denominadores foram rotulados de forma diferente, como diz a secção 2. Uso-a para mostrar que a precisão não foi a diferença evidente, não para afirmar que ambas são igualmente precisas.
O comentário de Kroah-Hartman sobre o Linux é uma frase. «Estou a ver o mesmo» é um sinal a acompanhar, não um resultado publicado.
A versão fácil desta história é David contra Golias. A versão útil é sobre o que significa um resultado vazio.
Dois dos sistemas de IA mais bem financiados do mundo olharam para um código muito auditado e disseram que não restava nada. Ambos descreviam com rigor a própria pesquisa. Um sistema mais estreito, com outra estratégia e com pessoas que verificavam o resultado antes de o enviar, encontrou seis vulnerabilidades reais em poucos dias. A taxa de acerto não era melhor. Simplesmente continuou e arrumou o que produzia.
Para um fundador que constrói sobre modelos de ponta, esta é a vantagem competitiva dita sem rodeios: profundidade num domínio e curadoria antes de qualquer coisa chegar a uma pessoa. Para um fundador que lança código, é um aviso igualmente direto.
Trata cada «sem resultados» como o limite da pesquisa de uma ferramenta, e regista por escrito onde ficava esse limite.
Fontes: AISLE, «AISLE Discovered Six curl CVEs After OpenAI and Anthropic Found Zero», Stanislav Fort, 2 de setembro de 2026 — as citações de Stenberg de 24 e 25 de agosto, os 29 relatórios, a passagem de três para dez CVE pendentes e a citação de Kroah-Hartman, tal como publicadas. Tabela de vulnerabilidades do curl para a 8.21.0 — os seis identificadores (CVE-2026-80229, -80230, -80231, -80255, -82208, -82209), os títulos, os intervalos de versões afetadas e a gravidade baixa. Daniel Stenberg, «Mythos finds a curl vulnerability», 11 de maio de 2026 — as cinco declaradas, a confirmada, os três falsos positivos, os cerca de vinte bugs e a avaliação de «sobretudo marketing». Steven Vaughan-Nichols, ZDNET, via Yahoo Tech, 4 de setembro de 2026 — o pormenor sobre o ZeroPath, as citações de Stenberg sobre a «era do caos de alta qualidade» e os «resultados cuidados», e o comentário de Jim Fuller. As afirmações da AISLE sobre junho vêm da sua publicação sobre a 8.21.0, incluindo a citação sobre a capacidade «irregular». A comparação de proporções da secção 2 e tudo a partir da secção 3 é meu. Para outro caso em que o próprio relatório do agente era justamente aquilo em que não se devia confiar, ver o teu agente de código fixou o commit. Para o argumento de que os modelos pequenos ganham nas decisões estreitas, ver a maior parte do que o teu agente pede a um LLM é um sim ou um não.
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
