Cosa espone davvero Squidbleed
Squidbleed, registrato come CVE-2026-47729, è una sovralettura di buffer nel parser degli elenchi di directory FTP di Squid, uno dei proxy web più diffusi di internet. Quando Squid rende un elenco FTP a cui manca il nome del file, un ciclo che salta gli spazi avanza di un passo di troppo e legge memoria oltre il buffer previsto. Poiché Squid riusa la memoria liberata tra le richieste, quei byte vaganti sono spesso frammenti del traffico di altri utenti: richieste HTTP in chiaro con password, cookie, token di sessione e chiavi API.
L'esposizione è più stretta di Heartbleed, ma reale. Un attaccante deve essere un utente autorizzato di un proxy condiviso e controllare un server FTP che il proxy può raggiungere sulla porta 21, il che punta il rischio verso gli interni e verso ogni configurazione in cui il proxy termina il TLS. Il traffico HTTPS inoltrato come tunnel opaco resta sigillato, quindi in gioco ci sono i flussi HTTP in chiaro e quelli terminati in TLS che ancora ogni giorno passano dai proxy aziendali.
Una riga, ventinove anni e la IA che l'ha trovato
La causa profonda è quasi banale. Il codice chiamava strchr su una stringa che poteva essere vuota, e lo standard C dice che strchr tratta il byte nullo finale come parte della stringa, quindi il controllo che doveva fermarsi alla fine dell'input è proseguito in silenzio oltre. Lo schema colpevole risale a un commit di Squid del gennaio 1997, il che significa che il difetto è stato distribuito nelle configurazioni predefinite, la porta 21 è nell'elenco predefinito Safe_ports, per ventinove anni attraverso innumerevoli versioni, riscritture e revisioni di sicurezza. La correzione è una sola condizione aggiunta, un controllo di null prima di strchr, oppure spegnere del tutto l'FTP, che Chromium ha abbandonato anni fa e su cui quasi nessuna rete fa più affidamento.
Il dettaglio che dovrebbe tenere l'attenzione di un operatore è chi l'ha trovato. Due ricercatori l'hanno segnalato in modo indipendente, Pavel Kohout di Aisle Research a marzo 2026 e Lam Jun Rong di Calif.io ad aprile, e i manutentori hanno unito la correzione in pochi giorni, con l'avviso pubblico il 23 giugno. Ma la scoperta originale è venuta da un agente di IA incaricato di percorrere la macchina a stati dell'FTP, non da un altro audit umano. La comoda convinzione che il codice vecchio e molto revisionato sia sicuro per la sua età ha appena fallito una prova molto pubblica, e lo strumento che l'ha rotta ora è economico e ampiamente disponibile.
Cosa dovrebbe fare un operatore questa settimana
Il passo concreto è piccolo: censisci ogni istanza di Squid che gestisci, aggiornala a una versione corretta e, se non ti serve di proposito il proxy FTP, disattivalo e togli la porta 21 da Safe_ports. Dai priorità a ogni proxy che termina il TLS o trasporta HTTP in chiaro per più utenti, perché è lì che le credenziali dei colleghi possono trapelare le une verso le altre. In Italia l'ACN tratta l'esposizione di credenziali su infrastruttura condivisa come un incidente da notificare, e in tutta l'UE il recepimento di NIS2 mette la responsabilità di un difetto noto e non corretto sui vertici designati, non solo sul team di sicurezza.
La mossa più grande è smettere di trattare l'età di una dipendenza come prova della sua sicurezza. Un difetto di una riga si è nascosto ventinove anni in software di cui migliaia di organizzazioni si fidavano proprio perché maturo, e un revisore di IA l'ha trovato in un solo passaggio. Aspettati che altri di questi difetti dormienti emergano nei tuoi componenti più vecchi e fidati, e metti a budget un flusso costante di piccole patch poco vistose invece di una sola clamorosa.
Da leggere ora: Due falle di Cursor con punteggio 9.8 consegnano la macchina dello sviluppatore agli aggressori | Una sola violazione di un fornitore ha causato metà delle vittime di ransomware in Europa
