O que o Squidbleed realmente expoe
O Squidbleed, registado como CVE-2026-47729, é uma sobreleitura de buffer no 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. Um 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 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 continuou em silêncio para além. O padrão culpado remonta a um commit do Squid de janeiro de 1997, o que significa que a falha foi distribuída em configurações predefinidas, a porta 21 consta da lista predefinida Safe_ports, 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, que o Chromium abandonou há anos e do qual 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, e os mantenedores integraram a correção em dias, com o aviso público a 23 de junho. Mas a descoberta original veio de um agente de IA encarregado de percorrer a máquina de estados do FTP, 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 falhar um teste muito público, e a ferramenta que a quebrou é agora barata e amplamente disponível.
O que um operador deve fazer esta semana
O passo concreto é pequeno: inventarie cada instância do Squid que executa, corrija para uma versão publicada 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. Em Portugal o CNCS trata a exposição de credenciais em infraestrutura partilhada como um incidente a notificar, e em toda a UE a transposição da NIS2 coloca a responsabilidade por uma falha conhecida e não corrigida na direção designada, 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 linha escondeu-se 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. Espere que mais destas falhas adormecidas surjam 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 dramática.
Leia a seguir: Duas falhas do Cursor com nota 9.8 entregam a máquina do programador aos atacantes | Uma única falha de fornecedor causou metade das vítimas de ransomware na Europa
