Uma Linha de Código Escondida por 29 Anos

Em janeiro de 1997, alguém corrigiu um bug no Squid Proxy para lidar com servidores FTP rodando NetWare. A correção funcionou. E durante quase três décadas, ninguém percebeu que ela abriu um buraco no proxy mais usado do mundo para cache HTTP.

O bug se chama Squidbleed (CVE-2026-47729), e ele permite que um atacante leia pedaços da memória do servidor proxy — incluindo headers de autenticação, cookies de sessão e chaves de API de outros usuários. Se você já ouviu falar do Heartbleed, a mecânica é parecida: um overread de heap que cospe dados que não deveriam sair dali.

A descoberta? Foi feita com ajuda do Claude Mythos Preview, o modelo de IA da Anthropic voltado para análise de código. O modelo identificou um comportamento obscuro da função strchr() no padrão C que sobreviveu a 29 anos de releases, auditorias e rewrites.

O Que É o Squid e Por Que Você Deveria Se Importar

Squid é um proxy de cache HTTP e HTTPS usado em redes corporativas, universidades, provedores de internet e hotspots públicos de Wi-Fi no mundo inteiro. Ele existe desde 1996 e é o tipo de software que ninguém lembra que está rodando — até que algo dá errado.

Se você trabalha em uma empresa que usa proxy para filtrar tráfego, cache de conteúdo ou controle de acesso, tem uma chance real de estar rodando Squid. Milhares de servidores ao redor do mundo usam esse software em produção, muitos deles em configurações padrão que nunca foram alteradas desde a instalação.

E é exatamente a configuração padrão que torna o Squidbleed tão perigoso.

A Anatomia do Bug: strchr e o Terminador Nulo

Vamos ao código. O problema mora na função htmlifyListEntry() dentro de src/Ftp/Gateway.cc. Essa função parseia listagens de diretórios FTP — aquelas respostas que o servidor manda quando você faz um LIST.

O trecho problemático é este:

if (flags.skip_whitespace) {
    while (strchr(w_space, *copyFrom))
        ++copyFrom;
}

Parece inofensivo, certo? O código pula espaços em branco antes de chegar ao nome do arquivo na listagem FTP. O problema é o que acontece quando não existe nome de arquivo depois do timestamp.

Uma listagem FTP normal se parece com isso:

drwxr-xr-x   2 root  root  4096 Jan 16 18:53 documents

Mas um servidor FTP malicioso pode mandar isso:

d [R----F--] supervisor            512       Jan 16 18:53

Sem nome de arquivo no final. O ponteiro copyFrom chega ao terminador nulo (\0) da string. E aqui entra o plot twist que faz qualquer programador C levantar uma sobrancelha.

O Footgun do C que Ninguém Lembra

Segundo o padrão C11, seção 7.24.5.2, o terminador nulo faz parte da string. Isso significa que strchr(w_space, '\0') não retorna NULL. Ele retorna um ponteiro para o próprio terminador nulo dentro de w_space.

Releia isso. A função que deveria dizer “não achei o caractere” está dizendo “achei sim, tá aqui”. Porque o \0 é considerado parte da string de busca.

O resultado: o loop while nunca para. O ++copyFrom avança o ponteiro além do buffer alocado, entrando em memória heap adjacente. O ASAN (AddressSanitizer) captura isso como um heap-buffer-overflow — leitura de até 4.065 bytes além do final de uma região de 4.096 bytes.

Uma leitura de 4KB de memória que pertence a outro processo. A outro usuário. A outra requisição HTTP que passou por ali minutos antes.

Por Que os Dados Antigos Ainda Estão na Memória

Aqui a coisa fica realmente interessante. Squid não usa malloc/free direto do sistema operacional. Ele mantém freelists próprias por tamanho de buffer — uma espécie de pool de memória para performance.

Quando um buffer de 4KB (MEM_4K_BUF) é “liberado”, ele não volta para o alocador do sistema. Ele vai para uma lista interna. Na próxima vez que alguém pedir um buffer de 4KB, o Squid pega o primeiro da lista e entrega — sem zerar o conteúdo.

Isso significa que se aquele buffer foi usado anteriormente para processar a requisição HTTP de outro usuário, os dados antigos ainda estão lá. O header Authorization: Basic dXNlcjpwYXNzd29yZA==, o cookie de sessão, a chave de API — tudo intacto nos bytes que o FTP parser não sobrescreveu.

A listagem FTP maliciosa ocupa apenas algumas dezenas de bytes no início do buffer. Os outros ~4.000 bytes ainda contêm dados da vítima. E o overread do strchr caminha por todos eles, copiando-os via xstrdup() para a resposta FTP que volta ao atacante.

O Ataque na Prática

Para explorar o Squidbleed, o atacante precisa de:

1. Um servidor FTP sob seu controle — acessível a partir do proxy
2. Uma vítima usando o mesmo proxy — fazendo requisições HTTP em texto claro
3. Nada mais — FTP está habilitado por padrão no Squid, e a porta 21 está na ACL Safe_ports por padrão

O fluxo do ataque funciona assim:

Não precisa de credenciais especiais. Não precisa de exploits sofisticados. Basta ser um usuário autorizado do proxy — o que é o caso em qualquer rede corporativa, escola ou café com Wi-Fi compartilhado.

O Que Pode Vazar

Os dados expostos dependem do que estava no buffer anteriormente:

• Headers Authorization — credenciais em texto claro ou Base64
• Cookies de sessão — tokens que permitem impersonar o usuário
• Chaves de API — tokens de acesso a serviços externos
• Dados de formulários — em requisições POST via HTTP
• URLs completas — revelando que páginas internas a vítima acessou

A limitação principal é que apenas tráfego HTTP em texto claro é vulnerável. Conexões HTTPS passam pelo proxy como um túnel opaco via CONNECT, e o proxy nunca vê o conteúdo. Mas em ambientes corporativos onde o proxy termina TLS (para inspeção de tráfego), todo o conteúdo descriptografado fica exposto.

E aqui mora o ironia: as empresas que implementam inspeção TLS “por segurança” são justamente as mais vulneráveis ao Squidbleed.

29 Anos de Auditorias que Não Viram Nada

O bug entrou no Squid em 18 de janeiro de 1997. Bill Clinton ainda era presidente dos EUA. O Google nem existia. Java tinha 2 anos de vida.

De 1997 até junho de 2026, o Squid passou por centenas de releases, múltiplos rewrites parciais, auditorias de segurança e contribuições de dezenas de desenvolvedores. Ninguém viu o problema.

E não é difícil entender por quê. O comportamento do strchr com o terminador nulo é uma daquelas “fun facts” do C que todo mundo aprende e esquece. É contra-intuitivo. A maioria dos programadores assume que strchr retorna NULL quando o caractere não é encontrado — e para qualquer caractere normal, isso é verdade. O \0 é o caso especial que ninguém testa.

O Calif.io, que liderou a divulgação responsável, usou o Claude Mythos Preview durante a investigação. O modelo reconheceu o comportamento do strchr conforme a especificação C11 imediatamente — algo que o olho humano passou batido por quase três décadas.

Não é a primeira vez que IAs encontram bugs antigos em projetos maduros. O próprio Claude encontrou um bug de 23 anos no kernel Linux em abril. Mas o Squidbleed tem um charme especial: é uma linha de código. Um *copyFrom && faltando. E esse && faltante ficou dormindo por 29 anos.

O Patch: Uma Linha

A correção é quase ofensiva de tão simples:

// Antes (vulnerável)
while (strchr(w_space, *copyFrom))
    ++copyFrom;

// Depois (corrigido)
while (*copyFrom && strchr(w_space, *copyFrom))
    ++copyFrom;

Adicionar *copyFrom && antes do strchr garante que o loop pare quando encontrar o terminador nulo. Sem overread. Sem vazamento de memória.

O patch foi mergeado no branch master/v8 em 19 de abril de 2026, dois dias após o reporte inicial de Lam Jun Rong do Calif.io. O backport para v7 veio em 17 de maio. A versão Squid 7.6 foi lançada em 8 de junho, mas o mantenedor Amos Jeffries esclareceu que o fix real para o CVE-2026-47729 só vai no Squid 7.7.

Como Se Proteger Agora

Se você administra um proxy Squid, aqui vai o checklist:

Opção 1 — Atualizar:

Atualize para Squid 7.7 (quando disponível) ou aplique o patch manualmente no seu build.

Opção 2 — Desabilitar FTP:

Adicione essas linhas ao squid.conf:

acl FTP proto FTP
http_access deny FTP

Opção 3 — Bloquear porta 21 no firewall:

Se você não usa FTP (e honestamente, quem usa em 2026?), bloqueie a porta 21 no perímetro da rede.

Opção 4 — Zerar buffers reciclados:

Se você tem acesso ao código-fonte, modifique o pool de memória para zerar buffers antes de reciclá-los. Isso adiciona overhead de CPU, mas elimina a classe inteira de vazamento de dados por reuso de memória.

Para verificar se você está vulnerável:

# Checar versão do Squid
squid -v | head -1

# Verificar se FTP está habilitado (padrão: sim)
grep -i "proto FTP" /etc/squid/squid.conf

# Se não encontrar nenhuma regra deny para FTP, você está vulnerável

A Comparação com o Heartbleed É Justa?

Sim e não.

O Heartbleed afetou uma fatia brutal da internet — qualquer servidor HTTPS rodando OpenSSL estava exposto. O Squidbleed tem um escopo menor: apenas proxies Squid processando tráfego HTTP ou terminando TLS. Mas nos ambientes onde ele importa — redes corporativas, escolas, ISPs — o impacto é real.

A semelhança conceitual é impressionante: ambos são overreads de heap onde o atacante recebe mais dados do que deveria, e ambos existiram por anos em código amplamente auditado.

O Papel da IA na Caça de Bugs

O Squidbleed reforça uma tendência que vimos crescer em 2026: modelos de IA sendo usados como ferramentas de auditoria de segurança em código legado.

O que o Claude Mythos fez aqui não foi “mágico”. Ele leu o código, reconheceu que o comportamento do strchr com \0 é definido pelo padrão C de uma forma que contradiz a intuição, e conectou os pontos. É o tipo de análise que um humano expert em C faria — se lembrasse desse detalhe da spec.

O problema é que humanos esquecem. Modelos treinados em milhões de linhas de código e dezenas de especificações de linguagem tendem a não esquecer essas edge cases. E quando você aponta um modelo desses para um codebase de 30 anos com centenas de milhares de linhas, ele pode encontrar coisas que três décadas de revisão humana não encontraram.

Eu já vi gente argumentar que “IA vai substituir security researchers”. Não vai. Mas quem não usar IA como ferramenta vai ficar para trás na caça de vulnerabilidades. O Squidbleed é evidência disso.

FTP em 2026: O Elefante na Sala

Talvez a pergunta mais óbvia seja: por que o Squid ainda suporta FTP por padrão em 2026?

FTP é um protocolo dos anos 70. Transmite credenciais em texto claro. Não tem criptografia nativa. A maioria dos navegadores modernos já removeu suporte a FTP. O Chrome matou FTP em 2021. O Firefox, em 2021 também.

Mas o Squid ainda habilita FTP por padrão, com a porta 21 na lista Safe_ports. E é exatamente esse suporte legado que abriu a porta para o Squidbleed.

A lição aqui não é nova, mas vale repetir: código legado que ninguém desabilita é superfície de ataque que ninguém monitora. Se você tem FTP habilitado no seu proxy e ninguém da sua equipe sabe dizer por quê, a resposta provavelmente é “porque sempre esteve ligado”.

Desliga.

O Que Vem Depois

O Squidbleed já tem patch disponível, mas a adoção vai demorar. Proxies corporativos são notoriamente difíceis de atualizar — muitos rodam versões antigas com configurações customizadas que ninguém quer mexer.

O site oficial do Squidbleed (squidbleed.xyz) lista os detalhes técnicos, um PoC e instruções de mitigação. Se você administra infraestrutura de rede, vale gastar 10 minutos verificando se o seu proxy está na lista de afetados.

E se você é dev e programa em C, faça um favor a si mesmo: releia a seção 7.24.5.2 do padrão C11. O strchr e o terminador nulo estão esperando para te pegar quando você menos esperar.

Fonte de inspiração: Squidbleed (CVE-2026-47729) — Calif.io | squidbleed.xyz