O Squidbleed (CVE-2026-47729) é uma vulnerabilidade de leitura de memória descoberta em junho de 2026 no Squid Proxy, presente no código desde 1997. Em configurações padrão, a falha permite que um cliente do proxy leia trechos da memória de outros usuários, expondo cabeçalhos Authorization, cookies de sessão e tokens de API em tráfego HTTP em claro. A correção está no Squid 7.6 e a recomendação de hardening é desabilitar o FTP.

Squidbleed: a falha que importa

Pesquisadores da Calif.io revelaram em 18 de junho de 2026 o Squidbleed (CVE-2026-47729), uma falha que silenciosamente vazou memória interna do Squid Proxy durante quase três décadas. O bug foi encontrado por um agente de IA da Anthropic revirando código escrito em 1997 e funciona de forma parecida com o lendário Heartbleed: em configurações padrão, ele entrega a um atacante pedacinhos de memória que pertenciam a outros usuários do mesmo proxy, incluindo cookies de sessão, tokens de API e cabeçalhos Authorization.

A diferença em relação ao Heartbleed é o cenário. Para explorar o Squidbleed, o atacante precisa ser um cliente “confiável” do proxy — alguém que já tem permissão de usá-lo. Parece restritivo, mas corresponde exatamente ao habitat natural do Squid: redes compartilhadas de escolas, escritórios, provedores de internet e Wi-Fi público, onde qualquer pessoa conectada vira cliente “confiável” do proxy.

O Squid Proxy no Brasil

O Squid Proxy é uma das peças de infraestrutura mais comuns do mundo e está em todo lugar no Brasil. Provedores regionais o usam para economizar banda em links caros, escolas técnicas e universidades o usam para filtrar conteúdo, redes corporativas o usam para inspeção de tráfego, e ele também costuma aparecer no Wi-Fi de aeroportos, hotéis e aviões. O próprio pesquisador da Calif esbarrou com uma versão vulnerável, com quase dez anos de idade, num voo comercial.

Em redes com restrição de banda — comum no Brasil fora dos grandes centros — um único Squid pode concentrar a navegação de centenas ou milhares de usuários simultâneos. Cada cabeçalho HTTP em claro que passa por ali é uma chance de vaza para qualquer outro cliente “confiável” do mesmo proxy. É exatamente o tipo de ambiente onde uma falha de leitura de memória vira problema real.

Raiz de 1997: NetWare e FTP

A falha mora no parser de listagem de diretórios FTP do Squid. O FTP não tem um formato padronizado para listar arquivos — cada servidor imprime algo parecido com a saída do ls -l, mas com variação suficiente entre implementações para fazer qualquer parser sofrer. Até o DJB, referência em segurança e criptografia, já escreveu sobre o pesadelo que é analisar essa saída com confiabilidade.

No final dos anos 90, o Squid precisou lidar com servidores FTP do NetWare, sistema operacional de rede da Novell que dominava servidores corporativos. O FTP do NetWare inseria quatro espaços em branco entre o horário e o nome do arquivo, em vez do único espaço usado pelos demais servidores. O commit bb97dd37a, de 18 de janeiro de 1997, adicionou um laço para pular esses espaços extras. O código, hoje em dia, está assim:

while (strchr(w_space, *copyFrom)) ++copyFrom;

Parece correto. Não é. O detalhe está numa das footguns favoritas da linguagem C: segundo a especificação C11, a função strchr considera o terminador NUL como parte da string. Ou seja, strchr não retorna NULL quando encontra o fim da string — retorna um ponteiro para o próprio terminador. Se um servidor FTP controlado pelo atacante enviar uma linha de listagem que termina logo depois do horário, sem nome de arquivo nenhum, o laço nunca para. Ele anda além do buffer e copia para o atacante tudo o que aparecer na frente, vendendo como se fosse o nome de um arquivo.

Como a memória vaza entre usuários

O overread por si só seria só um bug curioso. O que o transforma em problema grave é a forma como o Squid gerencia memória. Em vez de devolver buffers liberados para o sistema, o Squid mantém freelistas por tamanho e reutiliza os mesmos blocos sem zerá-los. O buffer de 4 KB usado para processar a listagem FTP é o mesmo tipo de buffer que armazena requisições HTTP de outros usuários.

Quando a vítima navega, seu pedido HTTP ocupa um desses buffers de 4 KB. Quando ela termina e o buffer é devolvido à freelist, a requisição continua lá, intacta. Pouco depois, o atacante dispara uma requisição FTP para seu próprio servidor. O Squid reutiliza o mesmo buffer, sobrescreve os primeiros bytes com a linha curta de listagem FTP — e o restante do bloco ainda contém a requisição HTTP da vítima. O overread caminha além do terminador e manda tudo para o atacante, disfarçado de nome de arquivo numa listagem HTML.

O resultado é o vazamento cruzado que batiza o bug: credenciais de uma vítima, lidas por outro usuário do mesmo proxy, sem que nenhum dos dois precise fazer nada de incomum. O The Hacker News confirma que a prova de conceito é pública e que o cabeçalho Authorization de outra pessoa pode ser recuperado em uma demonstração de laboratório.

O que pode ser roubado

O escopo é limitado, mas relevante. O alvo principal é HTTP em claro — sites antigos, APIs internas, painéis de administração e qualquer endpoint que ainda rode sobre HTTP sem TLS. Cabeçalhos Authorization com Basic Auth, cookies de sessão, tokens Bearer e chaves de API trafegando em claro são todos candidatos a vazar, do mesmo jeito que vazaram chaves em falhas CVSS 10 recentes em plataformas de IA.

HTTPS não é afetado por padrão, porque o Squid apenas repassa a conexão como um túnel CONNECT opaco e nunca enxerga o conteúdo. A exceção são configurações de SSL/TLS interception, em que o Squid faz man-in-the-middle do TLS para inspecionar tráfego corporativo. Nessas instalações, todo o tráfego HTTP dentro do HTTPS também passa por texto claro dentro do Squid e entra na janela de exposição.

O atacante também precisa que o proxy alcance um servidor FTP controlado por ele na porta 21. Como FTP e a porta 21 vêm habilitados por padrão na ACL Safe_ports, nenhuma configuração fora do comum é exigida. Em ambientes que fazem SSL bump com Squid, o caldo é completo: há muito mais material sensível passando por buffers reutilizáveis.

CVE-2026-50012: a segunda falha

O Squidbleed não veio sozinho. A versão 7.6 do Squid, lançada em 8 de junho de 2026, fechou também o CVE-2026-50012, um heap overflow no tratamento de cache_digest em compilações com --enable-cache-digests. É uma vulnerabilidade de classe diferente, com potencial de corrupção de memória, e não tem relação direta com o parser FTP — mas apareceu na mesma janela de divulgação e dá mais um motivo para atualizar.

O thread na oss-security registra discussão ativa entre mantenedores, incluindo Amos Jeffries e Salvatore Bonaccorso (Debian), sobre exatamente em qual versão o patch do Squidbleed entrou. Há alguma confusão entre 7.6 e 7.7, então o conselho dos especialistas é simples: não confie apenas no número da versão, confirme o patch.

IA descobre bugs de três décadas

O método de descoberta é metade da história. A Calif vinha usando modelos de IA para fazer bug hunting em código aberto — primeiro o Codex Cyber, da OpenAI, que achou o “HTTP/2 Bomb” contra nginx, Apache, IIS e Envoy; agora o Claude Mythos Preview, da Anthropic, que topou com o strchr do Squid quase de imediato. O prompt dado ao modelo foi, basicamente, “investigue melhor o comportamento do FTP state machine”. O modelo apontou a quirk do terminador NUL — um detalhe de especificação que revisores humanos varreram por quase trinta anos sem flagrar.

Para quem trabalha com segurança no Brasil, isso é sinal de mudança de paradigma. Não é mais só “IA escreve código”, é “IA encontra bugs em código legado que ninguém queria ler”. Projetos com parser velho, protocolos mal especificados (FTP, SMB, DNS) e interfaces de rede são os candidatos naturais. As equipes de blue team brasileiras que mantêm infraestrutura legada — bancos, prefeituras, universidades — precisam começar a olhar para esses ativos com olhos novos.

Como corrigir e se proteger agora

A correção é pequena: um cheque de terminador NUL antes das chamadas vulneráveis de strchr, mesclado no ramo de desenvolvimento em abril de 2026 e no ramo 7.x em maio. A tabela abaixo resume o status por versão e a ação esperada:

Versão do Squid Status Ação recomendada
8.x (dev) Corrigida Manter atualizada
7.6+ (lançada em 8/jun/2026) Patch incluído Confirmar patch e atualizar
5.7 (Debian stable) Vulnerável sem backport Aguardar backport do distro ou desabilitar FTP
Qualquer versão antiga (≤ 4.x) Vulnerável Desabilitar FTP imediatamente

A recomendação de hardening, no entanto, vai além do patch:

  • Atualize o Squid para 7.6 ou superior e confirme o patch específico, especialmente se você usa pacote de distribuição (o Debian empacota o Squid 5.7, então o backport precisa ser checado explicitamente).
  • Desabilite o FTP. É a recomendação dos próprios pesquisadores e a mais eficaz. O Chromium removeu suporte a FTP há anos e quase nenhuma rede moderna depende dele. Desligar o suporte ao FTP elimina toda essa superfície de ataque, qualquer que seja a versão instalada.
  • Restrinja a ACL Safe_ports. Remova a porta 21 das portas permitidas caso o FTP não possa ser desativado.
  • Evite SSL interception em proxies compartilhados com credenciais sensíveis, ou, se for inevitável, isole esses proxies de redes onde usuários não confiáveis tenham acesso. Para defesa de perímetro em redes brasileiras, vale pensar em camadas — o pfSense como firewall open-source costuma atuar lado a lado com o Squid nesses cenários.
  • Monitore logs do Squid em busca de requisições FTP incomuns vindas de clientes internos, especialmente em direção a servidores FTP externos não conhecidos.

Leia também: XSS e CSRF — Exploração e Defesa em Aplicações Web e falha crítica no Jenkins dando RCE em servidores CI/CD, dois outros cenários onde vazamento de credenciais em infraestrutura legada vira invasão real.

A SUSE classifica o Squidbleed como moderado, CVSS 6.5: o atacante precisa de algum nível de privilégio prévio (acesso ao proxy) e o impacto se restringe à confidencialidade, sem afetar integridade ou disponibilidade. Nada de pânico, mas a combinação “rede compartilhada + HTTP em claro + FTP habilitado” descreve uma fatia enorme da infraestrutura brasileira. Para esses ambientes, a orientação é única: atualize e desligue o FTP hoje.

Referências