PwnEscape: falla critica Linux nelle VM cloud

Una nuova vulnerabilità critica del kernel Linux, identificata come CVE-2026-99999 e soprannominata PwnEscape, può permettere a codice in esecuzione dentro una macchina virtuale di leggere porzioni di memoria del server host. È un problema importante perché colpisce il livello condiviso su cui si basa gran parte dell’infrastruttura cloud moderna, non una singola configurazione sbagliata di un fornitore.

Per un’azienda questo significa una cosa semplice: se usi servizi cloud, ambienti di sviluppo isolati, infrastrutture virtualizzate o server Linux multi-tenant, la protezione non dipende solo dal firewall o dall’antivirus. In casi come questo, conta soprattutto quanto rapidamente vengono aggiornati i sistemi host e quanto è solida la gestione operativa della piattaforma.

Che cosa è successo

La falla è stata resa pubblica il 15 ottobre 2026 da The Hacker News sulla base di una ricerca condotta da Paulos Yibelo di pwn.ai. La vulnerabilità riguarda il codice di rete del kernel Linux e non un prodotto specifico di un singolo provider.

Il ricercatore ha dimostrato che pacchetti di rete appositamente costruiti, inviati da dentro una macchina virtuale guest, possono provocare tre effetti:

• leggere memoria dell’host;
• mandare in crash l’host;
• arrivare, in ambiente di laboratorio, all’esecuzione di codice sull’host.

La dimostrazione della perdita di memoria è stata effettuata contro i sandbox di produzione di Vercel, e l’azienda ha confermato il risultato. Secondo quanto riportato, ogni pacchetto poteva restituire circa 32 byte di memoria dell’host, e l’operazione poteva continuare finché il guest continuava a inviare pacchetti.

Gli altri due scenari, crash ed esecuzione di codice, sono stati osservati dal ricercatore su sistemi propri configurati per replicare l’ambiente di Vercel. Lo stesso ricercatore ha precisato di non aver dimostrato l’esecuzione di comandi root in un ambiente di produzione di un fornitore.

Perché questa notizia è rilevante anche se non usi Vercel

Il punto più importante è proprio questo: non è un bug di Vercel. La vulnerabilità si trova nel kernel Linux lato host, cioè nello strato comune su cui poggiano molte piattaforme cloud e molti ambienti virtualizzati.

Vercel usa Firecracker microVM su host Amazon EC2 bare-metal per isolare i carichi di lavoro dei clienti. Ma il problema, secondo le fonti, non è nel meccanismo di isolamento di Firecracker: è nel kernel Linux che l’host esegue. Questo rende la questione più ampia del singolo provider e più vicina a chiunque utilizzi infrastrutture condivise.

In pratica, il rischio riguarda tutti gli scenari in cui più workload girano sulla stessa base host Linux: cloud pubblici, sandbox di sviluppo, ambienti CI/CD, piattaforme PaaS, e in alcuni casi anche infrastrutture private ben consolidate ma non aggiornate.

Quanto è grave davvero

La vulnerabilità è stata classificata con un punteggio 9,3 su 10, quindi Critical, nel record CVE pubblicato dai maintainer del kernel. Il database NVD statunitense aveva ricevuto la voce ma, al momento indicato dalla fonte, non aveva ancora completato la propria revisione.

C’è però un aspetto da interpretare correttamente: il vettore di attacco indicato è locale. In termini non tecnici significa che l’attaccante deve già eseguire codice dentro una VM guest. Non è una vulnerabilità che un aggressore esterno può sfruttare semplicemente inviando traffico da Internet verso il vostro sito aziendale.

Questo non la rende trascurabile. La rende invece particolarmente importante per i fornitori cloud, per chi offre ambienti condivisi a clienti o reparti diversi, e per le aziende che eseguono workload potenzialmente esposti a codice non pienamente fidato, come:

• pipeline di build;
• ambienti di test temporanei;
• sandbox applicative;
• esecuzione di plugin, script o workload di terze parti.

Al momento della pubblicazione, le fonti indicano che non risultano sfruttamenti reali in the wild e che la vulnerabilità non compare nel catalogo CISA delle vulnerabilità attivamente sfruttate.

Come funziona la correzione

La correzione consiste in una modifica al kernel Linux, identificata dal commit 6785011f8b16, scritta da Michael S. Tsirkin di Red Hat e integrata nel ramo principale del kernel.

La patch aggiunge un controllo per impedire che i dati di checksum di un pacchetto puntino all’interno dell’header IPv4 prima che il kernel li elabori. Il controllo viene applicato in cinque punti del codice di rete.

Un dettaglio importante: l’autore della modifica la definisce una misura di defence in depth, cioè un rafforzamento della difesa, e segnala che un controllo più completo sul percorso di ingresso dei pacchetti nel kernel richiede ancora lavoro. Per le aziende questo è un promemoria utile: una patch può essere risolutiva per il difetto noto, ma non sostituisce una strategia di hardening e monitoraggio più ampia.

Versioni corrette del kernel

Secondo il record CVE citato dalla fonte, queste sono le prime versioni corrette nei rami supportati:

• 5.10 → 5.10.272
• 5.15 → 5.15.223
• 6.1 → 6.1.190
• 6.6 → 6.6.159
• 6.12 → 6.12.113
• 6.18 → 6.18.57
• 7.2 → 7.2.11

Va però evitato un errore comune: molte distribuzioni Linux distribuiscono kernel personalizzati e possono includere una patch senza cambiare in modo evidente il numero versione. Per questo non basta guardare l’output di uname o fermarsi alla numerazione generale del kernel. Bisogna verificare il bollettino del proprio vendor e accertarsi che la correzione sia presente nel kernel dell’host realmente in esecuzione.

Cosa significa per la tua azienda

Per una PMI italiana, la domanda giusta non è “usiamo Vercel?” ma “abbiamo sistemi Linux virtualizzati o servizi cloud dove il fornitore esegue codice isolato su host condivisi?”. Se la risposta è sì, la priorità è verificare in tempi rapidi chi gestisce gli host e come vengono applicate le patch.

Ecco le azioni pratiche da mettere in agenda:

1. Chiedi subito conferma ai fornitori cloud o MSP
   Se usi hosting gestito, piattaforme PaaS, ambienti di sviluppo cloud o server virtuali amministrati da terzi, chiedi se gli host Linux sono stati aggiornati contro CVE-2026-99999 e con quali tempi.

2. Controlla gli host, non solo le VM guest
   La fonte è chiara: aggiornare solo il kernel della macchina virtuale guest non risolve il problema. La correzione deve essere applicata al sistema host e richiede il riavvio nel kernel corretto.

3. Verifica dove gira codice “non fidato”
   Se in azienda esistono ambienti in cui sviluppatori, consulenti o software di terze parti eseguono codice su piattaforme condivise, questi contesti vanno rivisti per primi.

4. Riduci l’impatto di un eventuale breakout
   Quando l’aggiornamento non è immediato, vale il principio del contenimento: separazione dei workload, privilegi minimi, segmentazione di rete, limitazione dell’accesso ai segreti applicativi e monitoraggio dei processi host.

5. Assicurati che backup e continuità operativa siano reali
   Poiché la vulnerabilità può arrivare anche al crash dell’host, è importante verificare procedure di ripristino e copie di sicurezza aggiornate. In quest’ottica possono essere utili soluzioni di remote backup.

6. Formalizza patch management e responsabilità
   Molte aziende scoprono troppo tardi di non sapere chi debba aggiornare cosa: provider, sistemista interno, consulente esterno o software house. Un contratto chiaro di presidio e manutenzione riduce i tempi di reazione. Se manca una governance precisa, conviene strutturarla con servizi di sicurezza informatica o con un supporto continuativo di gestione desktop e infrastruttura.

7. Valuta il profilo privacy e compliance
   Quando una vulnerabilità espone potenzialmente memoria di sistema, il tema non è solo tecnico: va valutato anche il possibile impatto su dati personali, credenziali e segreti aziendali. Se trattate dati di clienti, dipendenti o pazienti, può essere opportuno verificare anche gli aspetti di accountability previsti dal GDPR.

Cosa ci insegna il caso Vercel

C’è un aspetto interessante in questa vicenda: la vulnerabilità è emersa durante una challenge di sicurezza di due settimane organizzata da Vercel ad agosto, con un montepremi fino a 1 milione di dollari complessivi. Nessun singolo premio ha raggiunto quella cifra, ma l’iniziativa ha prodotto un risultato concreto: una debolezza critica è stata individuata, segnalata privatamente e corretta prima che risultassero abusi reali.

Per le aziende il messaggio è chiaro. La sicurezza non è l’assenza di problemi; è la capacità di scoprirli presto, gestirli bene e ridurre il danno possibile. Anche provider già considerati solidi possono essere toccati da vulnerabilità a livello di kernel, perché il rischio moderno si concentra sempre più nei componenti condivisi dell’infrastruttura.

Domande frequenti

Se aggiorno Linux dentro la mia VM, sono protetto?

No. In questo caso la correzione va applicata al kernel dell’host che esegue la virtualizzazione. Aggiornare solo la VM guest non elimina la falla.

È una vulnerabilità attaccabile direttamente da Internet?

No, secondo le fonti il vettore è locale: l’attaccante deve già poter eseguire codice all’interno di una macchina virtuale guest.

Devo preoccuparmi anche se uso solo servizi cloud gestiti?

Sì, ma in modo operativo: più che intervenire da solo, devi chiedere conferma ai fornitori su patch applicate, tempi di riavvio degli host e misure di contenimento adottate.