Una vulnerabilità critica nel firmware UEFI espone le infrastrutture di server e datacenter al rischio di esecuzione di codice malevolo durante l’avvio da rete. Identificata come CVE-2026-97631, ha un punteggio di gravità di 9,5 su 10 e interessa una base di codice utilizzata dalla maggior parte dei fornitori mondiali di server. Lo sfruttamento avviene durante la sequenza di avvio PXE, prima che possano intervenire le protezioni del sistema.
Il componente vulnerabile appartiene a TianoCore EDK II, il progetto open source con cui produttori hardware e fornitori cloud realizzano il firmware UEFI. AMI, Insyde e Phoenix ne utilizzano ampiamente il codice di riferimento. Anche Project Mu, la variante di EDK2 rafforzata sul piano della sicurezza da Microsoft, utilizzava il codice contenente il componente vulnerabile. Questa diffusione estende il problema a un ecosistema di prodotti e implementazioni differenti.
Il difetto è un buffer overflow presente da 16 anni nel driver PXE Base Code, che consente a server, apparati di archiviazione e altri dispositivi di avviarsi usando codice scaricato dalla rete locale. Durante questa procedura, il driver resta in ascolto di messaggi di errore ICMP e li copia in un campo di memoria di 504 byte. I gestori IPv4 e IPv6 calcolano in modo errato i limiti della copia: un messaggio troppo lungo può sovrascrivere i dati adiacenti con contenuti controllati dall’attaccante.
Il messaggio ostile può essere inviato all’indirizzo IP del dispositivo tramite un semplice pacchetto unicast, anche da qualsiasi distanza di rete, purché raggiunga il bersaglio durante l’avvio PXE. Un attacco può bloccare la sequenza di accensione e provocare un’interruzione del servizio. Conoscendo la specifica versione del firmware, l’aggressore può inoltre costruire un evento contraffatto che esegue codice nell’ambiente UEFI, in ring 0, il livello di privilegio più elevato della CPU.
L’esecuzione anticipata permette di intervenire prima che difese come Secure Boot possano proteggere la catena di fiducia dell’avvio. Gli exploit aggirano anche i processi di attestazione, utilizzati per dimostrare crittograficamente a sistemi remoti che l’hardware è sicuro. Il codice consegnato direttamente attraverso questa vulnerabilità viene eseguito una sola volta; può però aprire la strada all’installazione di altri componenti malevoli capaci di attivarsi nuovamente nelle prime fasi degli avvii successivi.
HD Moore, creatore di Metasploit e responsabile della ricerca della società di sicurezza Dragos, evidenzia la possibilità di dirottare l’esecuzione quando il processo di avvio ha ancora accesso a componenti sensibili, incluso il TPM. Secondo Moore, questa posizione potrebbe consentire di compromettere la cifratura del disco anche disponendo di un accesso temporaneo alla rete. Uno scenario di furto del dispositivo renderebbe l’operazione ancora più agevole.
La gestione della divulgazione ha accelerato l’esposizione del problema. Gli scopritori, Alex Matrosov di Anthropic e Dan Holmes di Google, avevano concordato di mantenere riservata la vulnerabilità fino a una pubblicazione coordinata prevista per gennaio. AMI ha invece pubblicato una richiesta di modifica al codice che descriveva il difetto e comprendeva la correzione. Quando gli scopritori ne sono venuti a conoscenza, i membri del progetto TianoCore hanno diffuso un avviso pubblico.
Il precedente più vicino è PixieFail, anch’esso legato a errori nell’avvio PXE di EDK2. LogoFail aveva invece sfruttato difetti nella gestione delle immagini dei loghi del firmware per sovvertire la catena di fiducia e installare componenti malevoli prima del caricamento del sistema operativo. Dopo PixieFail erano stati avviati diversi progetti di fuzzing, una tecnica di ricerca automatizzata degli errori: quegli sforzi sembrano non aver individuato questa falla.
La disponibilità pubblica della correzione offre agli attaccanti più esperti gli elementi per ricostruire il difetto e sviluppare exploit funzionanti. Per i difensori, invece, distribuire gli aggiornamenti del firmware richiede un percorso lungo e complesso: il codice deve arrivare a milioni di dispositivi commercializzati e utilizzati da migliaia di produttori hardware e fornitori cloud. È questa frammentazione a rendere laborioso il passaggio dalla correzione del progetto alla protezione delle infrastrutture operative.