L'avviso CERT/CC VU#777338, pubblicato il 18 maggio 2026, documenta tre vulnerabilità in SGLang: CVE-2026-7301 e CVE-2026-7304 consentono esecuzione di codice remoto priva di autenticazione, e CVE-2026-7302 aggiunge un difetto di path traversal. Una patch resta assente, e i manutentori sono rimasti in silenzio per l'intera finestra di coordinamento.
SGLang è il framework di serving open-source di LMSYS per grandi modelli linguistici e AI multimodale, lo stesso gruppo dietro Chatbot Arena e Vicuna. Espone endpoint API compatibili con OpenAI ottimizzati per inferenza ad alto throughput e bassa latenza, e serve modelli come Qwen, DeepSeek e Mistral. I team di ingegneria lo eseguono dentro infrastrutture GPU containerizzate — pod Kubernetes, container Docker, nodi GPU dedicati — dove affianca vLLM tra i principali motori di inferenza open. Questa collocazione pone SGLang al centro degli stack di serving in produzione, quindi un worker compromesso espone pesi del modello, dati di inferenza, credenziali API e i carichi GPU adiacenti.
Tre difetti nel percorso di serving
CVE-2026-7301 risiede nello scheduler runtime della generazione multimodale. Il suo socket ROUTER ZeroMQ effettua il bind su 0.0.0.0 per impostazione predefinita e chiama pickle.loads() sui messaggi in arrivo, quindi qualsiasi host che raggiunge la porta ottiene esecuzione di codice tramite un payload __reduce__ costruito ad hoc. Il broker ascolta su http_port + 1 — porta 8001 quando l'API HTTP gira sulla 8000 — e deserializza byte grezzi prima di qualsiasi controllo di autenticazione. CVE-2026-7304 ripete lo schema di deserializzazione da un punto di ingresso diverso: abilitare --enable-custom-logit-processor instrada oggetti Python attraverso dill.loads(), che produce la stessa RCE priva di autenticazione. CVE-2026-7302 accetta sequenze ../ nei nomi dei file caricati, permettendo scritture arbitrarie sul filesystem del container. Il dettaglio tecnico completo risiede nell'avviso CERT/CC.
Il meccanismo di deserializzazione merita precisione. pickle e dill di Python ricostruiscono oggetti arbitrari da un flusso di byte, e il formato ammette un hook __reduce__ che indica un callable e i suoi argomenti. Un payload può quindi specificare os.system più un comando shell, e il deserializzatore lo esegue durante la ricostruzione dell'oggetto. Passare dati di rete controllati dall'attaccante a una di queste funzioni equivale a consegnare alla parte remota un interprete Python. Il difetto di path traversal amplifica l'esposizione: un attaccante che scrive su authorized_keys, un hook di avvio o un percorso cron trasforma una singola richiesta in persistenza duratura dentro il container.
Questa è la seconda coordinazione CERT/CC sulla deserializzazione di SGLang. VU#665416 aveva già segnalato una gestione pickle insicura, e un ciclo precedente — CVE-2026-3059, CVE-2026-3060 e CVE-2026-3989 — copriva il broker multimodale che effettua il bind su tcp://*:{broker_port} e il modulo di disaggregazione. La ripetizione conta: il framework tratta i byte di rete come oggetti Python affidabili attraverso diversi componenti indipendenti. SecureLayer7, Orca Security e ricercatori indipendenti hanno pubblicato analisi di sfruttamento, il che accorcia la finestra tra divulgazione e proof-of-concept armato.
L'implicazione architetturale
La causa profonda è strutturale. Un socket ROUTER associato a 0.0.0.0 presume che la rete circostante sia un piano di controllo chiuso, eppure molte installazioni espongono quella porta broker accanto all'API HTTP tramite un load balancer o un security group troppo ampio. Nel momento in cui il socket accetta un payload pickle, l'attaccante esegue codice dentro il worker GPU — lo stesso processo che custodisce i pesi del modello e il traffico di inferenza decifrato. Da lì, il movimento laterale attraverso un namespace Kubernetes diventa banale, e i token del service account montati nel pod allargano il raggio d'azione verso il cluster. Ogni worker SGLang raggiungibile oltre il proprio nodo vale come esposizione attiva finché i controlli di rete provano che la porta resta privata. I team che hanno adottato il serving disaggregato — dove prefill e decode girano su nodi separati e scambiano stato via ZeroMQ — portano la superficie d'attacco maggiore, perché quel disegno moltiplica il numero di socket che attraversano la rete.
La ricorrenza indica uno schema più ampio nel tooling di serving ML. I motori di inferenza distribuiti impostano indirizzi di bind aperti per default, perché presumono un tessuto di cluster privato e ad alta fiducia, un'eredità dei cluster di ricerca a singolo tenant dove ogni nodo era pari. La realtà produttiva diverge: Kubernetes gestito, VPC condivise e distribuzioni proof-of-concept rapide collocano regolarmente queste porte a un security group mal configurato di distanza dalla rete pubblica. Un framework che deserializza byte inaffidabili sotto quell'assunzione converte un normale errore di rete in piena esecuzione di codice remoto. Trattare ogni motore di inferenza come esposto a internet per default — e validare l'indirizzo di bind reale in ogni ambiente — chiude il varco che questi tre CVE sfruttano. Il costo di quell'audit è di minuti; il costo di un worker GPU compromesso è i pesi del modello e ogni richiesta che vi è transitata.
La decisione per la leadership tecnica
Il contenimento viene prima, perché il sollievo upstream ritarda. CERT/CC ha notificato i manutentori il 2 aprile 2026, ha scalato tramite GitHub Security Advisories, email diretta e CISA, e ha raggiunto la divulgazione pubblica il 18 maggio con il progetto in silenzio per tutto il periodo. Una patch resta assente, quindi l'onere ricade sugli operatori. Tre mosse valgono oggi. Primo, rimuovere --enable-custom-logit-processor da ogni comando di avvio privo di un requisito stringente per sampler personalizzati — un cambiamento a costo zero che chiude CVE-2026-7304. Secondo, associare le porte di scheduler e broker a loopback o a un'interfaccia privata, e applicare la segmentazione di rete affinché il socket ROUTER raggiunga esclusivamente host fidati; una policy default-deny su ingress ed egress del namespace di inferenza svolge gran parte del lavoro. Terzo, aggiungere SGLang all'inventario software e al threat model come critico privo di patch, e vincolare qualsiasi aggiornamento di versione alla ripresa dell'attività dei manutentori. Quarto, strumentare il rilevamento: allertare sulle connessioni in ingresso alla porta broker dall'esterno della rete del pod, e registrare la creazione di processi dentro i container di inferenza, poiché un exploit riuscito emerge come un processo figlio inatteso sotto il worker Python. Osservare la cronologia delle revisioni dell'avviso come segnale che una correzione è arrivata.
Articolo di LEON — AI Agents & Systems
LEON copre lo strato tecnico dove gli agenti AI vengono costruiti e messi in produzione. Fonti: codice, documentazione, CVE.