Squid: un bug di 29 anni lascia leggere le password altrui

Un bug vecchio 29 anni nel proxy open source Squid permette a chi condivide la stessa rete di intercettare frammenti delle richieste HTTP in chiaro di altri utenti, comprese le credenziali che vi transitano. I ricercatori di Calif.io lo hanno scoperto e battezzato Squidbleed (CVE-2026-47729), in omaggio a Heartbleed, la falla che nel 2014 aveva esposto la memoria dei server con lo stesso meccanismo.

A individuare l'anomalia è stato, secondo i ricercatori, il modello Claude Mythos Preview di Anthropic, legato al cosiddetto Project Glasswing. Il caso si aggiunge alle falle sepolte in software open source molto diffuso che gli agenti IA stanno riportando alla luce, dopo episodi recenti come quello di FFmpeg. Sfruttare Squidbleed richiede due condizioni precise:

• l'attaccante deve già essere un utente autorizzato dello stesso proxy, lo scenario tipico di reti condivise come scuole, uffici o Wi-Fi pubblici;
• serve anche far raggiungere al proxy un server FTP sotto il suo controllo sulla porta 21, attiva di default insieme al supporto FTP.

Il leak riguarda solo il traffico che Squid riesce a leggere. Il normale HTTPS viaggia in un tunnel CONNECT opaco che il proxy non ispeziona, quindi resta esposto soltanto l'HTTP in chiaro, oltre alle configurazioni che terminano il TLS per decriptare e analizzare il traffico in transito.

Come funziona il bug Squidbleed

La falla si nasconde nel parser dei listati di directory FTP di Squid, scritto nel 1997 per gestire vecchi server NetWare che riempivano le righe con spazi superflui. Il codice li scarta con un ciclo basato sulla funzione strchr, pensato per fermarsi al primo carattere utile.

Se il server FTP dell'attaccante invia una riga che termina subito dopo il timestamp, senza alcun nome file, il puntatore finisce sul terminatore null della stringa. strchr lo considera comunque un carattere valido, il ciclo non si arresta, e il codice copia, oltre il limite del buffer, tutto ciò che trova in memoria, restituendolo come se fosse un nome file.

Quella memoria, nella maggior parte dei casi, non è vuota. Squid riutilizza i buffer liberati senza azzerarli, per cui un blocco da 4 KB che ospitava poco prima la richiesta di un'altra persona ne conserva ancora gran parte del contenuto. Nella demo dei ricercatori, l'over-read ha restituito un header Authorization sufficiente a impersonare la vittima. Il codice della proof of concept è pubblico su GitHub, e finora non sono state segnalate campagne di sfruttamento reali.

Patch e raccomandazioni

La correzione è minima, un controllo aggiuntivo prima delle chiamate strchr incriminate, è stata integrata nel ramo di sviluppo ad aprile 2026 e nella versione 7 a maggio 2026. Sulle versioni interessate la comunicazione è stata però contraddittoria: il maintainer Amos Jeffries ha indicato prima Squid 7.6, poi 7.7, come release corrette, mentre Debian ha segnalato che la patch sembra già presente nella 7.6.

Chi applica l'aggiornamento dovrebbe verificare la presenza del controllo direttamente nel file FtpGateway.cc, non limitarsi al numero di versione: le distribuzioni pacchettizzano build proprie, e Debian distribuisce ancora la vecchia Squid 5.7. La 7.6 corregge anche, separatamente, un overflow nel cache_digest catalogato come CVE-2026-50012, non collegato a Squidbleed.

La soluzione più semplice resta disattivare il supporto FTP nella configurazione di Squid: Chromium l'ha abbandonato da anni e la maggior parte delle reti non lo usa più, quindi rimuoverlo elimina la superficie di attacco a prescindere dalla versione installata. SUSE classifica la gravità come moderata, con un punteggio CVSS di 6,5: il vettore richiede infatti un accesso già autorizzato al proxy, e l'impatto resta limitato alla sola riservatezza dei dati, senza conseguenze su integrità o disponibilità del servizi.