Un frammento apparentemente innocuo, nato per gestire vecchi server FTP NetWare, si è trasformato nel cuore di una vulnerabilità capace di esporre richieste HTTP in chiaro, credenziali e token di autenticazione appartenenti ad altri utenti collegati allo stesso proxy. La falla è stata battezzata “Squidbleed”, un riferimento inevitabile a Heartbleed, perché il meccanismo è sorprendentemente simile: leggere memoria oltre i limiti previsti e restituirla all’attaccante.

Il problema riguarda Squid, storico software proxy ancora diffusissimo in ambienti enterprise, reti scolastiche, università, hotspot pubblici e infrastrutture aziendali. I ricercatori di Calif.io hanno classificato la vulnerabilità come CVE-2026-47729 e la sua peculiarità è la possibilità di sottrarre dati sensibili già transitati nella memoria del proxy.

La dinamica dell’attacco è più raffinata di quanto possa sembrare. L’attaccante deve essere un client già autorizzato a utilizzare lo stesso proxy Squid della vittima. In pratica, uno studente collegato alla rete scolastica, un dipendente in un ufficio o un utente connesso a un Wi-Fi pubblico possono tentare di intercettare traffico appartenente ad altri utenti della medesima infrastruttura.

Il bug vive all’interno del parser FTP di Squid, componente ormai considerata quasi archeologica ma ancora attiva nella configurazione predefinita. Ed è proprio questo dettaglio ad aumentare la superficie di rischio, dal momento che molti amministratori moderni non utilizzano più FTP, eppure lasciano il supporto abilitato semplicemente perché incluso di default.

Tecnicamente, l’errore nasce da una gestione difettosa degli spazi bianchi nelle directory listing FTP. Il codice coinvolto utilizza una chiamata a strchr() per avanzare oltre i caratteri whitespace. Il comportamento inatteso emerge quando il server FTP controllato dall’attaccante invia una riga priva del nome file finale. In quella condizione il puntatore raggiunge il terminatore nullo della stringa, ma strchr() considera quel carattere come parte valida della ricerca, impedendo al ciclo di interrompersi.

Da quel momento il parser continua a leggere memoria oltre il buffer originario. È il classico heap over-read, per cui il software oltrepassa i limiti previsti e copia dati residui presenti in memoria, restituendoli al client malevolo sotto forma di falso filename FTP.

Il vero problema emerge dal modo in cui Squid gestisce la memoria interna. I buffer liberati non vengono azzerati prima del riutilizzo e ciò significa che una porzione di RAM usata pochi istanti prima per memorizzare la richiesta HTTP di un’altra persona può conservare quasi intatto il contenuto originale. Se l’input FTP inviato dall’attaccante è sufficientemente corto, soltanto i primi byte vengono sovrascritti, lasciando il resto della memoria disponibile all’estrazione.

La dimostrazione pubblicata da Calif.io mostra un caso estremamente concreto, ovvero l’estrazione di un header Authorization appartenente a un altro utente del proxy. In termini pratici, equivale alla possibilità di impersonare la vittima in determinati servizi web, soprattutto quando il traffico viene ancora gestito in HTTP o in configurazioni TLS terminate direttamente dal proxy.

Questo punto è fondamentale per comprendere l’effettiva portata della vulnerabilità. Squidbleed non rompe HTTPS tradizionale quando il proxy si limita a creare un tunnel CONNECT cifrato. In quello scenario Squid non vede il contenuto del traffico. Il rischio interessa invece il traffico HTTP in chiaro oppure le installazioni aziendali che implementano SSL inspection, pratica molto diffusa nei sistemi di controllo e filtraggio corporate dove il proxy decripta il traffico TLS per analizzarlo.

L’exploit richiede inoltre che il proxy possa raggiungere un server FTP controllato dall’attaccante sulla porta 21. Anche qui emerge un altro elemento quasi anacronistico, nel senso che FTP è ormai largamente abbandonato nel mondo consumer. Chromium lo ha eliminato anni fa e gran parte del traffico moderno non lo utilizza più. Tuttavia Squid continua a mantenerne il supporto attivo, trasformando codice legacy in una vulnerabilità contemporanea.

La correzione introdotta dagli sviluppatori è relativamente semplice. È stato aggiunto un controllo esplicito sul terminatore nullo prima delle chiamate incriminate a strchr(). Il fix è arrivato nel ramo di sviluppo ad aprile e successivamente nella serie v7 a maggio, anche se la situazione delle versioni corrette ha generato confusione tra maintainer e distributori Linux. Per alcune ore si è parlato della versione 7.6 come release sicura, salvo poi correggere l’informazione indicando la 7.7. Debian, dal canto suo, sostiene che parte della patch fosse già inclusa nei pacchetti distribuiti.

Uno degli aspetti più interessanti dell’intera vicenda riguarda il ruolo dell’intelligenza artificiale nell’identificazione del bug. Calif.io attribuisce infatti a Claude Mythos Preview di Anthropic la capacità di individuare quasi immediatamente il comportamento anomalo di strchr(). È un segnale molto indicativo dell’evoluzione del vulnerability research moderno, con parser dimenticati, codice legacy e controlli mancanti che stanno diventando terreno ideale per strumenti AI specializzati nell’analisi automatica del software.

(Immagine in apertura: Shutterstock)