Che cosa espone davvero Squidbleed
Squidbleed, registrato come CVE-2026-47729, è una sovralettura di buffer nell'heap all'interno del parser degli elenchi di directory FTP di Squid, uno dei proxy web più diffusi di internet. Quando Squid mostra un elenco FTP in 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 una richiesta e l'altra, 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ù ristretta di quella di Heartbleed, ma reale. L'attaccante deve essere un utente autorizzato di un proxy condiviso e deve controllare un server FTP che il proxy possa raggiungere sulla porta 21, il che sposta 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 oggi attraversano ogni giorno i proxy aziendali.
Una riga, ventinove anni e l'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 stabilisce che strchr tratta il byte nullo finale come parte della stringa, così il controllo che avrebbe dovuto 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 compare nell'elenco predefinito Safe_ports, per ventinove anni e 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 trattenere l'attenzione di un operatore è chi lo ha trovato. Due ricercatori lo hanno segnalato in modo indipendente, Pavel Kohout di Aisle Research a marzo 2026 e Lam Jun Rong di Calif.io ad aprile, i manutentori hanno integrato la correzione nel giro di pochi giorni e l'avviso pubblico è arrivato il 23 giugno. Ma la scoperta originale è venuta da un agente di IA incaricato di percorrere la macchina a stati dell'FTP, e non da un altro audit umano. La comoda convinzione che il codice vecchio e molto revisionato sia sicuro in virtù della sua età ha appena fallito una prova molto pubblica, e lo strumento che l'ha smontata ormai costa poco ed è alla portata di tutti.
Che cosa dovrebbe fare un operatore questa settimana
Il passo concreto è piccolo: censite ogni istanza di Squid che gestite, aggiornatela a una versione corretta e, se non vi serve deliberatamente il proxy FTP, disattivatelo e togliete la porta 21 da Safe_ports. Date 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. Nel Regno Unito il National Cyber Security Centre tratta l'esposizione di credenziali su infrastruttura condivisa come una categoria di incidente da notificare, e in tutta l'UE il regime NIS2 pone la responsabilità di un difetto noto e non corretto sui vertici aziendali indicati per nome, e non soltanto sul team di sicurezza.
La mossa più ampia è smettere di trattare l'età di una dipendenza come prova della sua sicurezza. Un difetto di una sola riga si è nascosto per ventinove anni in un software di cui migliaia di organizzazioni si fidavano proprio perché maturo, e un revisore di IA lo ha trovato in un solo passaggio. Aspettatevi che altri difetti dormienti come questo emergano nei vostri componenti più vecchi e più fidati, e mettete a budget un flusso costante di piccole patch poco vistose invece di una sola patch clamorosa.
Da leggere ora: Un audit di IA non ha visto il bug Linux che dà root | Questo malware cancella prima i tuoi backup
