Pesquisadores da Calif usaram o Claude Mythos Preview para encontrar um bug que vivia escondido desde 1997. A falha, batizada de Squidbleed e registrada como CVE-2026-47729, atinge o Squid Proxy. Esse software roda em redes corporativas, escolas e Wi-Fi público pelo mundo inteiro. Ou seja, milhões de requisições passam por ele todos os dias.

A seguir, você entende como o bug funciona, por que ninguém o viu antes e o que isso significa para quem escreve código em C.

Claude Mythos achou o que três décadas de auditoria deixaram passar

Primeiro, vale registrar o tamanho do feito. O código vulnerável já tinha sobrevivido a quase trinta anos de revisões, auditorias e reescritas. Mesmo assim, o modelo da Anthropic apontou o problema quase de imediato. Além disso, ele citou a cláusula exata do padrão C11 que explica o comportamento perigoso.

Para um desenvolvedor, esse é o detalhe mais provocativo. A máquina não chutou. Ela leu o módulo de FTP, entendeu a semântica da linguagem e indicou a linha culpada.

O bug que dormia dentro do strchr desde 1997

Agora vamos ao núcleo técnico. O Squid usa um trecho de código para interpretar listagens de diretórios em servidores FTP. Quando o servidor retorna uma linha sem nome de arquivo, o código começa a ler além do espaço reservado.

A raiz do problema está na função strchr, da linguagem C. Ao buscar pelo caractere nulo que encerra a string, ela retorna um ponteiro válido para ele. Portanto, não sinaliza ausência de resultado. O código então avança além daquele ponto e segue lendo.

O que vem depois na memória pode ser qualquer coisa. Como o Squid reaproveita blocos de memória sem limpá-los, esses blocos guardam requisições HTTP de outros usuários. Dessa forma, um atacante recupera cabeçalhos de autenticação, tokens de sessão e chaves de API que trafegam em HTTP comum.

Claude Mythos leu o código e citou a cláusula exata do C11

Aqui mora a lição de engenharia. A falha é sutil porque depende de um comportamento técnico, e não de um erro óbvio. O caractere nulo faz parte da string, afinal. Por isso, poucos revisores humanos pensariam em testar esse caso específico.

A correção, por outro lado, é mínima. Bastam duas linhas que checam se o ponteiro chegou ao fim da string antes de chamar a função. Em resumo, trinta anos de risco contra duas linhas de validação.

Por que seu proxy ainda pode estar vazando credenciais agora

Vamos ao impacto prático. A falha afeta qualquer instalação do Squid com suporte a FTP ativo, que é justamente o padrão. O atacante precisa controlar um servidor FTP acessível pelo proxy. Em ambientes corporativos e legados, isso é totalmente viável.

Por outro lado, conexões HTTPS normais ficam de fora. O Squid as trata como túneis opacos e não lê o conteúdo. Ainda assim, os pesquisadores encontraram o Squid rodando até em Wi-Fi de bordo de aviões, em versões com quase dez anos de atraso.

Claude Mythos não parou no Squid: OpenSSL e HTTP/2 também caíram

Esse caso não é isolado. A mesma abordagem já tinha revelado uma vulnerabilidade grave no OpenSSL. Além disso, identificou uma técnica de negação de serviço no protocolo HTTP/2.

Logo, a mensagem para a comunidade dev fica clara. A revisão assistida por IA deixou de ser promessa e virou ferramenta de auditoria real. Quem mantém código antigo em C tem agora um aliado para varrer décadas de legado.

O que fazer hoje para fechar a brecha

Por fim, vamos à parte acionável. A correção entrou no Squid 8 em abril de 2026 e chegou à versão 7.6 em junho de 2026. Portanto, atualizar é o caminho principal.

Se você não puder atualizar agora, desative o suporte a FTP. Assim, a superfície de ataque desaparece por completo. Como a maioria das organizações já não usa FTP de forma legítima, o custo operacional é quase nulo.

No fim das contas, o Squidbleed entrega duas lições. A primeira é técnica: cuidado com a semântica de funções de string em C. A segunda é estratégica: a IA já lê o seu código melhor do que três décadas de revisores humanos.