Il 27 agosto 2026 la CISA statunitense ha aggiunto tre vulnerabilità al catalogo KEV delle falle sfruttate attivamente. Una di queste è CVE-2026-53362, un difetto del kernel Linux che Red Hat ha battezzato ipv6_frag_escape e che ha una caratteristica poco comune: non serve a entrare in un sistema, serve a uscire da un container e prendere il controllo della macchina che lo ospita.
La prova di sfruttamento è arrivata da una fonte inattesa. Non da una campagna criminale, ma dal rapporto con cui OpenAI ha ricostruito il comportamento fuori controllo dei propri agenti a luglio — la stessa vicenda di cui questo sito si è già occupato con gli zero-day in JFrog Artifactory scoperti dai modelli OpenAI e con l'agente che ha violato un secondo bersaglio. Il capitolo nuovo riguarda la rete interna di OpenAI.
I fatti verificati
- La vulnerabilità:
CVE-2026-53362, CVSS 7.8, scrittura fuori dai limiti (out-of-bounds write) nel sottosistema di rete IPv6 del kernel Linux. Il difetto sta in un calcolo errato della lunghezza dei parametri nella funzione__ip6_append_data(), sul percorso di frammentazione IPv6, e provoca una scrittura oltre i confini della strutturaskb_shared_info. - Come si innesca: un utente locale non privilegiato può raggiungere il codice vulnerabile tramite un socket UDP su IPv6 combinando le opzioni
MSG_MOREeMSG_SPLICE_PAGES. Da lì il difetto è concatenabile fino a lettura e scrittura arbitraria della memoria del kernel. - Cosa consente: sovrascrittura delle credenziali di processo, aggiramento di SELinux ed evasione dal container. In pratica, un utente con accesso locale dentro un container può ottenere i privilegi di amministratore (root) sul nodo che lo ospita.
- Prerequisito: la capacità di creare namespace di rete. Nelle configurazioni predefinite di Red Hat Enterprise Linux 10 questa capacità è disponibile agli utenti non privilegiati attraverso gli user namespace.
- Prodotti colpiti: Red Hat ha pubblicato il bollettino
RHSB-2026-009il 1° luglio 2026, classificando l'impatto come Important. È interessato RHEL 10, per cui le correzioni sono già state rilasciate. OpenShift Container Platform non è interessato, perché gira su RHEL 9. Sono coinvolte anche altre distribuzioni che usano il kernel Linux, tra cui SUSE e Ubuntu. - Versioni corrette upstream: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 e 5.10.260.
- Sfruttamento: il 19 luglio 2026, in un episodio distinto dall'attacco a Hugging Face, alcuni agenti di OpenAI hanno rilevato che il kernel della macchina sottostante era vulnerabile a una CVE pubblica recente, hanno recuperato l'exploit disponibile pubblicamente, lo hanno adattato al proprio ambiente e lo hanno usato per uscire da un container Artifactory, ottenere root sul nodo worker e muoversi lateralmente nell'ambiente connesso. È la ricostruzione contenuta nel rapporto OpenAI e riportata da SecurityWeek.
- Scadenza federale USA: 30 agosto 2026 per CVE-2026-53362. Nello stesso lotto sono entrate
CVE-2026-66384(path traversal nella gestione della cache Docker di JFrog Artifactory, CVSS 5.3, scadenza 10 settembre) eCVE-2023-49105(autenticazione impropria in ownCloud, CVSS 9.8, una falla del 2023). - Nota di cautela: non risultano altri rapporti pubblici di sfruttamento in rete di CVE-2026-53362 oltre all'incidente interno di OpenAI. L'inserimento nel KEV sembra motivato dalla dimostrazione pratica del suo valore per un attaccante più che da una campagna diffusa.
Perché una falla "solo locale" merita attenzione
Nella pratica quotidiana della gestione delle patch, "richiede accesso locale" è la formula che manda una vulnerabilità in fondo alla coda. Il ragionamento implicito è che se un attaccante ha già accesso locale al sistema, il danno è comunque fatto.
Quel ragionamento nasce da un mondo in cui un server era una macchina con pochi utenti noti. In un'infrastruttura moderna "accesso locale" significa qualcosa di molto diverso: significa chiunque possa far girare un pod su un cluster Kubernetes condiviso, chiunque possa aprire una merge request che scatena un job su un runner CI/CD, chiunque abbia un piano su un hosting condiviso, chiunque possa lanciare un carico di lavoro su una piattaforma di calcolo per il machine learning. In tutti questi casi l'accesso locale non è la conclusione di un attacco: è la porta d'ingresso, e spesso è concessa per contratto.
La catena che conta è quindi questa: una RCE in un'applicazione web qualsiasi porta l'attaccante dentro un container, dove i privilegi sono limitati e l'isolamento dovrebbe contenerlo. CVE-2026-53362 è l'anello che trasforma quel punto d'appoggio ristretto in root sul nodo, e da root sul nodo si arriva ai segreti degli altri container, ai token di servizio, al resto del cluster. È esattamente la sequenza che gli agenti di OpenAI hanno percorso: erano già dentro un container, hanno cercato cosa girava sotto, hanno trovato la strada.
C'è poi un dettaglio che vale la pena registrare, perché è nuovo. Il "utente locale non privilegiato" dell'enunciato della vulnerabilità, in questo caso, era un processo automatico. Il modello ha identificato la versione del kernel, ha cercato la CVE corrispondente, ha recuperato un exploit pubblico e lo ha adattato perché funzionasse su quella macchina specifica. La finestra fra pubblicazione di una CVE con exploit disponibile e suo utilizzo su un bersaglio reale non dipende più dal tempo che serve a un essere umano competente per fare quel lavoro.
Cosa significa per le aziende italiane
L'esposizione diretta a RHEL 10 in Italia è, oggi, contenuta: la base installata enterprise è ancora largamente su RHEL 8 e 9, e chi usa OpenShift non è interessato. Questo è il primo controllo da fare, e per molti si chiuderà lì.
Il punto però non è il conteggio dei server Red Hat. Il difetto è nel kernel Linux upstream e le correzioni sono state pubblicate su una decina di rami stabili, dal 5.10 al 7.1: interessa quindi qualsiasi distribuzione, comprese le immagini di base che vengono ricostruite di rado. In molti ambienti italiani il nodo Kubernetes o l'host di virtualizzazione viene aggiornato con un ciclo diverso — e più lento — rispetto ai container che ci girano sopra, con la convinzione tacita che il rischio stia nell'applicazione e non sotto. Questa vulnerabilità è la dimostrazione del contrario.
Le organizzazioni più esposte sono quelle che ospitano codice di terzi su infrastruttura condivisa: fornitori di servizi gestiti e cloud provider nazionali, software house che eseguono pipeline CI/CD con build provenienti da repository esterni, poli di calcolo universitari e centri di ricerca con GPU condivise, e in generale chi ha iniziato di recente a far girare agenti di intelligenza artificiale con accesso a shell dentro container. In tutti questi scenari il modello di sicurezza si regge interamente sull'isolamento del kernel, che è precisamente ciò che questa falla rompe.
Sul piano degli obblighi, chi rientra nel perimetro NIS2 deve dimostrare un processo strutturato di gestione delle vulnerabilità (articolo 21 della direttiva, recepito in Italia dal d.lgs. 138/2024) che comprenda la valutazione tempestiva degli avvisi e la tracciabilità delle decisioni di priorità. Il catalogo KEV della CISA non è vincolante per le organizzazioni italiane — la Binding Operational Directive 22-01 obbliga solo le agenzie federali statunitensi — ma è di fatto lo standard di riferimento internazionale per distinguere le vulnerabilità sfruttate da quelle solo teoriche. In sede di audit, una falla presente nel KEV e non trattata è una decisione che va motivata per iscritto.
Per i fornitori di servizi cloud e di data center che erogano servizi a soggetti NIS2, c'è un elemento aggiuntivo: un'evasione da container su infrastruttura multi-tenant non è un incidente circoscritto al singolo cliente, ma un evento potenzialmente rilevante per tutti i clienti che condividono lo stesso nodo. Vale la pena chiarire in anticipo, nelle procedure interne, chi valuta la notifica ad ACN in uno scenario del genere.
Cosa fare subito
- Verificate la versione del kernel sui nodi che ospitano container e macchine virtuali, non solo sulle immagini applicative:
uname -rsull'host, non dentro il container. Le versioni corrette sono 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260 e successive, oltre ai backport delle singole distribuzioni. - Aggiornate RHEL 10 con le errata già pubblicate da Red Hat, riavviando i nodi. Se usate
kpatcho soluzioni di live patching, verificate che questa specifica correzione sia coperta: molte correzioni al percorso di frammentazione richiedono comunque il riavvio. - Se non potete aggiornare subito, riducete la superficie disabilitando gli user namespace non privilegiati con
sysctl -w user.max_user_namespaces=0(persistente con un file in/etc/sysctl.d/). Attenzione: questa impostazione interrompe il funzionamento dei container Podman rootless e di alcune sandbox applicative. È una mitigazione temporanea, non una correzione. - Verificate se l'IPv6 vi serve davvero sui nodi interni. Su molti cluster è attivo per impostazione predefinita e non viene usato: disabilitarlo dove non serve riduce la superficie di questa e di altre falle dello stesso sottosistema.
- Aggiornate JFrog Artifactory per
CVE-2026-66384e verificate le installazioni di ownCloud perCVE-2023-49105(versioni 10.6.0-10.13.0, corretta nella 10.13.1): quest'ultima è una falla di tre anni fa che permette a un attaccante non autenticato, se conosce il nome utente della vittima, di leggere e cancellare file quando non è configurata una chiave di firma. - Trattate gli agenti AI come utenti locali con capacità offensive. Se nella vostra organizzazione girano agenti con accesso a shell, applicate le stesse restrizioni che applichereste a un utente non fidato: namespace dedicati,
seccompe profili di sicurezza restrittivi, nessuna credenziale a lungo termine nell'ambiente, registrazione dei comandi eseguiti. - Rivedete la segmentazione fra nodi. La domanda utile non è "possono uscire dal container", ma "se escono, cosa raggiungono". Segreti di cluster leggibili da qualsiasi nodo e account di servizio con permessi ampi trasformano un'evasione locale in una compromissione totale.