UEFI, falla nel PXE nascosta per 16 anni: i server si attaccano prima dell'avvio

Una vulnerabilità critica nel firmware UEFI rischia di compromettere la sicurezza di numerosi server utilizzati nei data center, nelle infrastrutture aziendali e nei servizi cloud. Il problema, identificato come CVE-2026-97631 e classificato con un punteggio CVSS di 9,5 su 10, permette a un aggressore di eseguire codice malevolo durante l’avvio della macchina, prima ancora che il sistema operativo possa applicare le proprie protezioni.

La falla interessa TianoCore EDK II, un’implementazione open source delle specifiche UEFI utilizzata come base di sviluppo da numerosi produttori di firmware, tra cui AMI, Insyde e Phoenix; anche Project Mu, la versione di EDK II sviluppata e rafforzata da Microsoft, ha utilizzato il componente coinvolto. La diffusione del codice rende il problema particolarmente delicato: una vulnerabilità introdotta in una libreria condivisa può propagarsi a prodotti di aziende differenti e rimanere presente per anni.

Nel 2023, le vulnerabilità LogoFail mostrarono come il caricamento di immagini nel firmware potesse aprire la strada all’esecuzione di codice non autorizzato. Poco dopo, PixieFail evidenziò problemi nei componenti di avvio tramite rete. Ora emerge un errore ancora più antico, presente nel codice da circa 16 anni, che coinvolge nuovamente le funzionalità di rete del firmware.

La gravità è elevata ma non tutti i server sono vulnerabili o possono subire un attacco semplicemente perché collegati a Internet.

CVE-2026-97631: la vulnerabilità si nasconde nel driver PXE di EDK II

Il componente vulnerabile è NetworkPkg/UefiPxeBcDxe, un driver che implementa parte delle funzionalità PXE (Preboot Execution Environment), tecnologia che consente a un computer di avviarsi utilizzando risorse disponibili in rete anziché affidarsi esclusivamente a un dispositivo di archiviazione locale.

Servendosi di PXE, gli amministratori possono distribuire sistemi operativi, reinstallare server, effettuare attività di manutenzione e predisporre nuove macchine senza intervenire fisicamente su ciascun dispositivo.

Durante un avvio PXE, il client può ottenere tramite DHCP le informazioni necessarie alla configurazione della rete, recuperare un programma di avvio attraverso TFTP e proseguire con il caricamento dell’ambiente richiesto. Le implementazioni più moderne possono utilizzare anche altri protocolli, ma il principio rimane sostanzialmente invariato: parte della procedura di avvio dipende dalla comunicazione con sistemi remoti.

Il driver interessato gestisce anche alcuni messaggi ICMP (Internet Control Message Protocol), utilizzati dai protocolli IP per segnalare errori e condizioni particolari nella comunicazione. Il problema emerge quando il firmware riceve un messaggio ICMP opportunamente costruito durante la fase di avvio tramite rete.

Secondo l’advisory ufficiale pubblicato da TianoCore, un aggressore capace di raggiungere il client con un messaggio ICMP può provocare una corruzione della memoria e, in condizioni specifiche, ottenere l’esecuzione di codice arbitrario.

Come un messaggio ICMP corrompe la memoria UEFI

La causa della vulnerabilità è un classico buffer overflow, aggravato da un errore nel calcolo degli offset durante la copia dei dati ricevuti dalla rete.

Il driver PXE conserva le informazioni relative agli errori ICMP in un campo denominato Mode.IcmpError, che dispone di una capacità fissa di 504 byte. Quando arriva un messaggio, il codice deve trasferirne il contenuto in quest’area di memoria, rispettandone le dimensioni.

Due funzioni presenti nel firmware e dedicate alla gestione degli errori ICMP per IPv4 e IPv6, non eseguono correttamente tale operazione. Un aggressore che riesce a sfruttare queste lacune può interferire con componenti che operano a un livello di privilegio estremamente elevato.

Le conseguenze possibili sono infatti almeno due, con livelli di gravità differenti:

• Disponibilità del sistema. Un messaggio ICMP malevolo può compromettere i dati interni del driver e provocare un’eccezione del processore durante l’elaborazione successiva. Il risultato può essere il blocco dell’avvio, impedendo al server di completare il caricamento del sistema operativo o di avviare una procedura di ripristino.
• Alterazione del flusso di esecuzione. Il secondo scenario è molto più pericoloso. Se l’aggressore conosce sufficientemente bene la versione e la disposizione delle strutture in memoria del firmware bersaglio, può costruire dati capaci di modificare il comportamento del sistema in avvio.

TianoCore descrive l’eventualità che il processore possa arrivare ad eseguire istruzioni controllate dall’attaccante con privilegi equivalenti al ring 0 dell’architettura x86 (il livello di privilegio più elevato del processore, normalmente riservato al kernel del sistema operativo).

Il codice malevolo interviene prima dell’avvio del sistema operativo, quando antivirus, strumenti EDR e normali meccanismi di protezione del kernel non sono ancora operativi.

Perché Secure Boot e TPM non bastano a fermare l’attacco

Verificare l’integrità dei componenti caricati durante l’avvio non equivale a garantire che ogni driver del firmware sia privo di vulnerabilità.

UEFI Secure Boot utilizza una catena di fiducia basata su firme digitali e chiavi autorizzate per controllare i componenti eseguibili soggetti alla relativa politica di verifica, a partire dal caricamento del software di avvio del sistema operativo.

Il chip Trusted Platform Module (TPM), attraverso le funzionalità di measured boot, può invece registrare misurazioni crittografiche di determinate componenti della sequenza di avvio. Tali informazioni consentono, tra le altre cose, verifiche di integrità e procedure di attestazione.

CVE-2026-97631 sfrutta però un difetto del codice già in esecuzione nel firmware: un driver legittimo, eventualmente incluso in un’immagine UEFI firmata, può comportarsi in modo inatteso quando elabora dati esterni malevoli.

Di conseguenza, Secure Boot non può impedire direttamente lo sfruttamento del buffer overflow; anche le misurazioni TPM non garantiscono il tempestivo rilevamento di una temporanea manipolazione della memoria.

HD Moore, creatore di Metasploit e oggi responsabile della ricerca presso Dragos, ha evidenziato anche il possibile coinvolgimento di dati sensibili e delle protezioni della cifratura del disco.

Quali server sono realmente vulnerabili?

La diffusione di EDK II rende CVE-2026-97631 potenzialmente rilevante per moltissimi sistemi: il codice TianoCore costituisce infatti una base comune per firmware commerciali e implementazioni personalizzate utilizzate da produttori hardware e fornitori cloud.

Non esiste però, al momento, un inventario pubblico completo dei server vulnerabili. Affinché una macchina possa “mostrare il fianco” agli attaccanti, devono presentarsi diverse condizioni: il firmware deve includere il componente vulnerabile, la macchina deve eseguire la procedura PXE interessata e l’aggressore deve riuscire a raggiungerla con un messaggio ICMP durante quella finestra temporale. Firewall, segmentazione, filtri ICMP e configurazioni di rete possono impedire il recapito del messaggio al client.

Inoltre, la possibilità di causare un blocco non implica necessariamente che sia altrettanto semplice ottenere l’esecuzione di codice.

Come osservato da Jesse Michael di Eclypsium, un exploit affidabile deve tenere conto delle caratteristiche della specifica versione del firmware, compresi gli indirizzi delle strutture in memoria.

Portavoce di Intel hanno fatto presente che nessuno dei suoi prodotti commerciali ancora supportati risulta attualmente interessato, precisando però che i produttori di schede madri possono integrare autonomamente il codice vulnerabile. Arm ha indicato che il problema non riguarda direttamente il proprio portafoglio prodotti.