AWS corregge due falle in EKS e Firecracker: a rischio l’isolamento delle risorse cloud

🛡️ Executive Summary

• Amazon EKS presenta una vulnerabilità di isolamento della rete. CVE-2026-122266 permette a un utente autenticato con accesso a un workload di aggirare le NetworkPolicy di ingresso verso pod ospitati sullo stesso nodo, anche in namespace differenti.
• Firecracker espone la memoria del processo di virtualizzazione. CVE-2026-122192 può consentire a un utente root nel guest di leggere o modificare la memoria del processo Firecracker in particolari condizioni di ripristino da snapshot.
• AWS pubblica le correzioni e delimita l’impatto. EKS richiede versioni aggiornate dell’agente di rete e del VPC CNI, mentre Firecracker è corretto nelle versioni 1.16.2 e 1.17.0. AWS Lambda non risulta coinvolto.

Amazon Web Services pubblica il 4 novembre 2026 due nuovi bollettini di sicurezza che interessano componenti fondamentali dell’isolamento delle infrastrutture cloud. La prima vulnerabilità, CVE-2026-122266, riguarda Amazon EKS e consente di aggirare determinate regole di ingresso delle Kubernetes NetworkPolicy attraverso una gestione impropria delle informazioni condivise nell’agente di rete. La seconda, CVE-2026-122192, interessa Firecracker, il sistema di virtualizzazione leggero utilizzato anche nell’ecosistema serverless, e permette in condizioni specifiche a un amministratore del guest di accedere alla memoria del processo di virtualizzazione. I due problemi hanno cause differenti e non costituiscono una catena di attacco comune. Entrambi, però, dimostrano come il funzionamento delle barriere fra workload dipenda da componenti software che devono essere aggiornati e verificati.

Amazon EKS: CVE-2026-122266 permette di aggirare le NetworkPolicy

Il primo problema riguarda aws-network-policy-agent, componente open source dell’Amazon VPC Container Network Interface incaricato di applicare le regole Kubernetes NetworkPolicy nei cluster Amazon Elastic Kubernetes Service. Nel bollettino ufficiale 2026-170-AWS, Amazon descrive una vulnerabilità derivante dall’isolamento improprio delle informazioni di tracciamento delle connessioni condivise attraverso eBPF. Un utente autenticato, in grado di trasmettere frame opportunamente costruiti da un workload, può alterare lo stato utilizzato dall’agente per prendere decisioni sulle comunicazioni di rete. Il risultato è un possibile bypass delle regole di ingresso verso pod collocati sullo stesso nodo, compresi pod appartenenti a namespace differenti. La vulnerabilità, classificata con CVSS 8,7, non equivale a un accesso remoto universale ai cluster: richiede condizioni specifiche e un punto d’appoggio in un ambiente di rete adiacente. L’impatto riguarda soprattutto riservatezza e integrità, perché un workload può raggiungere servizi dai quali dovrebbe essere isolato. AWS non segnala invece una compromissione della disponibilità dell’agente o dei pod come conseguenza diretta del difetto.

Leggi anche: CISA porta Cisco ISE, Acronis e Pixel nel KEV, AWS corregge il bypass EKS

Le correzioni EKS richiedono l’aggiornamento dell’agente e del VPC CNI

La correzione di CVE-2026-122266 è disponibile in aws-network-policy-agent 1.3.7 e Amazon VPC CNI 1.22.3. Le versioni precedenti sono indicate come vulnerabili, mentre il security advisory pubblicato nel repository del progetto conferma la possibilità di superare le regole di ingresso attraverso la manipolazione delle mappe eBPF utilizzate per il connection tracking. AWS specifica che non sono disponibili workaround, pertanto l’intervento raccomandato consiste nell’aggiornare i componenti coinvolti, comprese eventuali versioni derivate o personalizzate. Per i responsabili della sicurezza Kubernetes questo significa verificare non soltanto la versione del control plane, ma soprattutto quella dei componenti che applicano materialmente le politiche ai nodi. Una configurazione NetworkPolicy formalmente corretta non garantisce infatti l’isolamento se l’agente incaricato di interpretarla può essere indotto a prendere decisioni errate. La nuova vulnerabilità è distinta da CVE-2026-86831, altra falla EKS documentata a settembre: in entrambi i casi il confine fra namespace diventa rilevante, ma la causa tecnica non è la stessa. Nei cluster che ospitano applicazioni di clienti o reparti differenti, la verifica delle comunicazioni consentite tra pod rappresenta quindi un controllo particolarmente importante dopo l’aggiornamento.

Firecracker: la falla CVE-2026-122192 interessa la memoria delle microVM

Il secondo bollettino riguarda Firecracker, Virtual Machine Monitor open source progettato per eseguire microVM con un’infrastruttura di virtualizzazione ridotta. La vulnerabilità CVE-2026-122192, illustrata nell’advisory 2026-169-AWS, emerge in condizioni particolari durante il ripristino di macchine virtuali da snapshot. Quando viene utilizzato il backend di memoria File, in combinazione con dispositivi balloon o virtio-mem, un’operazione di scarto della memoria che non viene completata correttamente può lasciare il processo Firecracker in uno stato vulnerabile. In queste circostanze, un utente che dispone già di privilegi root all’interno del guest può potenzialmente leggere o modificare parti della memoria del processo di virtualizzazione. È un problema significativo perché supera il normale limite entro cui il sistema guest dovrebbe poter operare, pur senza dimostrare automaticamente il controllo completo del sistema host o l’accesso ai dati di altri clienti. La distinzione è essenziale: non si tratta di una vulnerabilità che chiunque può sfruttare semplicemente raggiungendo una microVM attraverso Internet. È necessario disporre di privilegi elevati nel sistema virtualizzato e soddisfare le condizioni tecniche descritte da AWS.

Firecracker 1.16.2 e 1.17.0 correggono il difetto, Lambda non è coinvolto

La vulnerabilità interessa Firecracker dalla versione 0.23.0 alla 1.16.1, comprese le release 1.16.0 e 1.16.1 ancora presenti nelle linee supportate. La correzione è integrata in 1.16.2 e 1.17.0. AWS consiglia agli operatori che utilizzano snapshot con backend File e dispositivi balloon oppure virtio-mem di aggiornare il software, integrando le stesse modifiche nelle eventuali distribuzioni derivate. In attesa della patch, una mitigazione consiste nell’utilizzare il backend di memoria Uffd, rispettandone i requisiti per la gestione delle pagine scartate. L’azienda indica anche alcune condizioni dell’host che possono ridurre il rischio di fallimenti nella sostituzione delle mappature di memoria, precisando tuttavia che non rappresentano una protezione completa. Il punto più importante per gli utilizzatori dei servizi gestiti è la delimitazione dell’impatto: AWS dichiara esplicitamente che Lambda e gli altri servizi AWS interessati dalla propria valutazione non sono vulnerabili, e che i clienti di tali servizi non devono effettuare interventi. Il problema interessa principalmente chi gestisce direttamente Firecracker nelle configurazioni coinvolte, situazione diversa dall’utilizzo ordinario di un ambiente serverless amministrato dal provider.

Continua con:

AWS corre ai ripari: patch critiche di aprile per Firecracker, Athena, RES e strumenti di sviluppo

Cloudflare Containers espone dati tra tenant: il bug rompe l’isolamento cloud

Due difetti diversi mostrano quanto sia delicato l’isolamento nel cloud

La pubblicazione contemporanea dei due bollettini richiama l’attenzione su un problema architetturale ricorrente: l’isolamento non dipende soltanto dalla configurazione visibile agli amministratori, ma anche dalla correttezza del codice che la applica. In Kubernetes le NetworkPolicy possono essere aggirate quando lo stato delle connessioni condiviso fra workload non viene adeguatamente separato. Nella virtualizzazione leggera, una gestione errata delle operazioni sulla memoria può invece compromettere il confine fra il guest e il processo che ne controlla l’esecuzione. Gli scenari non dimostrano una compromissione generalizzata di Amazon EKS o AWS Lambda e i bollettini non presentano evidenze pubbliche di sfruttamento attivo. Per gli amministratori di infrastrutture EKS è prioritario verificare e aggiornare le versioni di agente e VPC CNI; per chi utilizza Firecracker autonomamente, controllare versioni, modalità di ripristino delle snapshot e impostazioni della memoria. La sicurezza cloud richiede dunque una distinzione precisa tra servizi gestiti dal provider, componenti open source installati dal cliente e configurazioni operative vulnerabili, perché da questa separazione dipendono sia la valutazione del rischio sia la responsabilità degli interventi correttivi.