EDK2 UEFI: falla CVE-2026-97631 nel boot PXE dei server

È pubblica una vulnerabilità critica, CVE-2026-97631 (punteggio 9.5 su 10), in TianoCore EDK II (EDK2), il codice open source di riferimento con cui produttori di hardware e fornitori cloud costruiscono il firmware UEFI che avvia i server. Il difetto si trova nel driver che gestisce l’avvio dalla rete (PXE) e permette di eseguire codice prima che il sistema operativo si carichi e prima che Secure Boot verifichi qualsiasi componente.

Le fonti analizzate sono Ars Technica (ripubblicato integralmente da Wired) e Security Affairs, che cita l’avviso ufficiale del progetto; di The Hacker News abbiamo solo il titolo, che conferma i punti principali.

Una divulgazione arrivata in anticipo

La falla è stata scoperta da ricercatori di Anthropic e di Google, che avevano concordato una divulgazione coordinata per gennaio. Secondo Ars Technica, a settembre AMI ha pubblicato una pull request che descriveva il difetto e conteneva la correzione; quando i ricercatori se ne sono accorti, il progetto TianoCore ha diffuso l’avviso pubblico. Con la patch visibile, ricostruire il meccanismo di attacco diventa molto più semplice per chi ha le competenze, mentre la distribuzione degli aggiornamenti firmware su milioni di macchine richiederà tempo.

Dettagli tecnici

Il difetto ha circa 16 anni e si trova nel driver PXE Base Code (NetworkPkg/UefiPxeBcDxe). Durante l’avvio dalla rete il driver tiene aperta una ricezione per i messaggi ICMP di errore e copia ciascun messaggio in un campo fisso di 504 byte, Mode.IcmpError. Secondo l’avviso, nei gestori IPv4 e IPv6 (PxeBcIcmpErrorDpcHandle e PxeBcIcmp6ErrorDpcHandle) il controllo dei limiti è sbagliato:

• un messaggio più lungo di 504 byte viene copiato lo stesso;
• il puntatore di destinazione avanza della lunghezza cumulativa invece che di quella del singolo frammento;
• nessun controllo precedente limita la lunghezza del messaggio.

Il risultato è una scrittura di byte scelti dall’attaccante oltre il campo, nella memoria della fase DXE del firmware. L’avviso classifica il problema come Out-of-bounds Write, Classic Buffer Overflow e Incorrect Calculation of Buffer Size, con impatto su riservatezza, integrità e disponibilità.

Come si sfrutta

• Il messaggio malevolo è un semplice unicast verso l’indirizzo IP del dispositivo, da inviare mentre è in corso l’avvio PXE, su IPv4 o IPv6, senza autenticazione.
• Con dati non validi l’avvio si blocca (DoS).
• Conoscendo la build esatta del firmware, l’attaccante può far eseguire il proprio codice nell’ambiente UEFI, in ring 0, aggirando anche l’attestazione che dovrebbe dimostrare a server remoti che la macchina è integra.
• Il codice non è persistente, ma può servire a installare altri componenti che si eseguono a ogni avvio.

HD Moore (Dragos), citato da Ars Technica, osserva che a quel punto il processo di avvio ha ancora accesso a componenti come il TPM: con un accesso breve alla rete, o con un dispositivo rubato, si potrebbe arrivare a violare la cifratura del disco.

I limiti

• Serve un certo controllo della rete locale: è uno scenario da insider o da attaccante già entrato, che cerca di elevare i privilegi. Le fonti concordano che non ci sono prove che la falla serva come accesso iniziale.
• Secondo Jesse Michael (Eclypsium), l’exploit va adattato a ogni modello, versione e configurazione, perché gli indirizzi di memoria cambiano.
• Nessuna fonte segnala exploit pubblici o sfruttamento in corso.

Come tecniche MITRE ATT&CK pertinenti (nostra classificazione) si possono indicare T1542 Pre-OS Boot (in particolare T1542.001, System Firmware) e T1068 Exploitation for Privilege Escalation.

Chi è colpito

Sono esposti i sistemi con firmware basato su EDK2 che si avviano dalla rete con PXE, funzione che secondo Ars Technica è attiva per impostazione predefinita. Non sono colpiti i dispositivi domestici e dei piccoli uffici né chi avvia solo da disco.

Il perimetro esatto non è ancora chiaro:

• AMI, Insyde e Phoenix usano ampiamente EDK2, e anche Project Mu di Microsoft conteneva il componente vulnerabile;
• Intel dichiara che nessun suo prodotto commerciale ancora supportato risulta colpito, ma che un produttore di schede o di sistemi può aver integrato la funzione;
• Arm afferma che la CVE «non è direttamente applicabile» ai suoi prodotti;
• AMD, Phoenix, AMI, Microsoft e Amazon non avevano risposto alle domande di Ars Technica al momento della pubblicazione.

Le fonti non parlano delle macchine virtuali: molte piattaforme di virtualizzazione usano firmware UEFI derivati da EDK2, quindi conviene chiedere anche ai fornitori di hypervisor e cloud se le VM con avvio dalla rete sono coinvolte.

Impatto per le aziende europee e italiane

L’avvio PXE è comune nei data center, nel provisioning automatico dei server e nella distribuzione delle immagini di sistema. Per i soggetti NIS2, in particolare fornitori di servizi digitali, data center e cloud, la falla rientra nella gestione delle vulnerabilità e nella sicurezza della catena di fornitura: serve un inventario dei firmware e una richiesta formale ai fornitori. Nella sanità, dove server e postazioni vengono spesso preparati dalla rete, vanno controllati anche gli ambienti di provisioning. Vista la diffusione, HD Moore ritiene probabile che la falla resti a lungo nei sistemi non più supportati.

Cosa fare subito

1. Fai l’inventario dei sistemi che si avviano dalla rete e dei loro firmware (produttore, modello, versione BIOS/UEFI).
2. Chiedi ai produttori dei server e dei firmware se sono colpiti e quando arriverà l’aggiornamento. Secondo Eclypsium la correzione è un normale aggiornamento BIOS/UEFI: non servono revoche né aggiornamenti delle chiavi di Secure Boot (PK, KEK, db, dbx).
3. Disattiva l’avvio PXE dove non serve, almeno temporaneamente, come suggeriscono le fonti.
4. Dove serve, isola le reti di provisioning in segmenti dedicati e limita chi può inviare traffico verso le macchine in avvio (nostra indicazione generale).
5. Tieni attivi TPM e Secure Boot: restano utili, anche se non fermano questo attacco.
6. Controlla i log di rete per tentativi di sfruttamento, per esempio messaggi ICMP di errore insolitamente lunghi o frammentati verso macchine in avvio PXE.

Come aiuta ARXDOME

ARX Sentry raccoglie l’inventario hardware e di sistema delle macchine con l’agent, un punto di partenza per capire quali server verificare con i produttori. ARX Watch ascolta la rete con le sonde già installate e mostra anche i dispositivi senza agent, utile per non dimenticare macchine nei segmenti di provisioning. I log dei firewall raccolti da ARX Sentry arrivano nelle pagine SOC, dove si possono esaminare gli eventi che riguardano questi segmenti.

Ultimo aggiornamento: 28 ottobre 2026