O que o Squidbleed realmente expõe
O Squidbleed, registado como CVE-2026-47729, é uma sobreleitura de buffer na heap, dentro do analisador de listagens de diretórios FTP do Squid, um dos proxies web mais implantados da internet. Quando o Squid apresenta uma listagem FTP à qual falta o nome do ficheiro, um ciclo que salta espaços avança um passo a mais e lê memória para além do buffer previsto. Como o Squid reutiliza a memória libertada entre pedidos, esses bytes perdidos são muitas vezes fragmentos do tráfego de outros utilizadores: pedidos HTTP em texto simples com palavras-passe, cookies, tokens de sessão e chaves de API.
A exposição é mais estreita do que a do Heartbleed, mas real. O atacante tem de ser um utilizador autorizado de um proxy partilhado e tem de controlar um servidor FTP que o proxy consiga alcançar na porta 21, o que aponta o risco para os internos e para qualquer montagem em que o proxy termine o TLS. O tráfego HTTPS reencaminhado como túnel opaco permanece selado, portanto o que está em jogo são os fluxos HTTP em texto simples e os fluxos terminados em TLS que ainda passam todos os dias pelos proxies das empresas.
Uma linha, vinte e nove anos, e a IA que a encontrou
A causa de raiz é quase banal. O código chamava strchr sobre uma cadeia que podia estar vazia, e a norma C diz que strchr trata o byte nulo final como parte da cadeia, por isso a verificação que devia parar no fim da entrada seguiu em silêncio para além dele. O padrão culpado remonta a um commit do Squid de janeiro de 1997, o que significa que a falha foi distribuída nas configurações predefinidas, a porta 21 consta da lista predefinida Safe_ports, e isto durante vinte e nove anos, ao longo de incontáveis versões, reescritas e revisões de segurança. A correção é uma única condição acrescentada, uma verificação de nulo antes de strchr, ou desligar o FTP por completo, algo que o Chromium fez há anos e de que quase nenhuma rede ainda depende.
O detalhe que deveria prender a atenção de um operador é quem a encontrou. Dois investigadores comunicaram-na de forma independente, Pavel Kohout da Aisle Research em março de 2026 e Lam Jun Rong da Calif.io em abril, os mantenedores integraram a correção em poucos dias e o aviso público saiu a 23 de junho. Mas a descoberta original veio de um agente de IA encarregado de percorrer a máquina de estados do FTP, e não de outra auditoria humana. A cómoda suposição de que o código antigo e muito revisto é seguro pela sua idade acabou de chumbar num teste muito público, e a ferramenta que a derrubou é agora barata e está ao alcance de qualquer um.
O que um operador deve fazer esta semana
O passo concreto é pequeno: faça o inventário de cada instância do Squid que executa, atualize para uma versão corrigida e, se não precisar deliberadamente do proxy FTP, desative-o e retire a porta 21 do Safe_ports. Dê prioridade a qualquer proxy que termine o TLS ou transporte HTTP em texto simples para vários utilizadores, porque é aí que as credenciais dos colegas podem vazar umas para as outras. No Reino Unido, o National Cyber Security Centre trata a exposição de credenciais em infraestrutura partilhada como uma categoria de incidente sujeita a notificação, e em toda a UE o regime NIS2 coloca a responsabilidade por uma falha conhecida e não corrigida na direção de topo designada pelo nome, e não apenas na equipa de segurança.
O movimento maior é deixar de tratar a idade de uma dependência como prova da sua segurança. Uma falha de uma única linha escondeu-se durante vinte e nove anos em software em que milhares de organizações confiavam precisamente por ser maduro, e um revisor de IA encontrou-a numa única passagem. Conte com o aparecimento de mais falhas adormecidas como esta nos seus componentes mais antigos e de maior confiança, e orce um fluxo constante de pequenas correções pouco vistosas em vez de uma única correção dramática.
Leia a seguir: Auditoria de IA não viu a falha Linux que dá root | Este malware apaga primeiro os seus backups
