Un server aggiornato a livello di sistema operativo può restare esposto prima ancora che Linux o Windows partano. È il caso di CVE-2026-97631, una vulnerabilità nel driver PXE di EDK II: il punto pratico, per una PMI, non è inseguire il titolo più allarmistico, ma capire quali macchine usano davvero il network boot e chi deve fornire il firmware corretto.

Il controllo richiede meno tempo di un fermo non pianificato e produce un inventario riutilizzabile anche per le prossime vulnerabilità UEFI.

Capire se il problema riguarda i tuoi server

L’advisory ufficiale di TianoCore descrive un buffer overflow nel componente NetworkPkg/UefiPxeBcDxe. Durante un avvio PXE su IPv4 o IPv6, un attaccante capace di consegnare messaggi ICMP alla macchina può corrompere memoria nella fase DXE ed eseguire codice prima del caricamento del sistema operativo. La gravità dichiarata è 9,5 su 10, ma questo numero non significa che ogni PC o server sia automaticamente vulnerabile.

Servono condizioni precise: il dispositivo deve effettuare il boot dalla rete, il firmware deve includere il componente interessato e l’attacco deve raggiungerlo durante quella finestra. Il primo controllo è quindi binario: PXE è attivo e viene usato? Se una macchina avvia soltanto da disco locale, questo specifico percorso di attacco non si applica. Per i sistemi gestiti da un provider, non dedurre l’esposizione dal marchio della CPU: chiedi una conferma sul modello e sulla build firmware effettivamente distribuita.

Costruisci un inventario che porti a una decisione

Apri un foglio o un ticket e registra per ogni server quattro dati: produttore e modello, versione BIOS/UEFI, stato del network boot e referente che gestisce gli aggiornamenti. Non basta scrivere “server Dell” o “VM cloud”: la vulnerabilità vive nel firmware della piattaforma, quindi la risposta utile deve riferirsi a una combinazione precisa di hardware e versione. Se il server è in colocation, chiarisci anche chi può accedere alla console remota e applicare l’update.

Invia poi al vendor una domanda verificabile: “Questo modello, con questa versione firmware e PXE abilitato, include il driver EDK II interessato da CVE-2026-97631?”. Chiedi il numero della release corretta, il link all’advisory e gli eventuali prerequisiti. È lo stesso metodo che conviene usare per le patch critiche nello stack WordPress: inventario, versione installata, versione risolta e responsabile della finestra di manutenzione. Una risposta generica del commerciale non chiude il rischio; serve una dichiarazione tecnica applicabile al sistema censito.

Riduci l’esposizione mentre aspetti il firmware

Se PXE non serve, disabilitalo nel firmware e rimuovilo dall’ordine di boot. Prima di farlo su macchine remote, verifica però che non sia parte del ripristino, del provisioning automatico o del piano di disaster recovery: una mitigazione applicata senza contesto può trasformarsi in un server non avviabile quando serve davvero. Se il network boot è necessario, separa la rete di provisioning, limita i percorsi ICMP non indispensabili e controlla chi può raggiungere quel segmento. Queste misure riducono la superficie, ma non sostituiscono l’aggiornamento indicato dal produttore.

Pianifica il firmware come una modifica infrastrutturale: backup della configurazione, verifica dell’alimentazione ridondata, console fuori banda funzionante, finestra di rollback e controllo finale della versione. Mantieni Secure Boot e TPM attivi dove previsti, sapendo che l’advisory colloca l’esecuzione prima dei normali controlli del sistema operativo. Dopo l’intervento, documenta esito e data; una verifica della catena tecnica, come per i certificati TLS, vale solo se lascia una prova consultabile.

L’errore da evitare: patchare senza perimetro

Il titolo “vulnerabilità UEFI critica” spinge facilmente a due reazioni sbagliate: aggiornare tutto alla cieca oppure rimandare finché non esce una lista universale dei prodotti coinvolti. Ars Technica segnala che il codice EDK II è molto diffuso, ma riporta anche che il quadro dei dispositivi interessati non è ancora completo e che l’exploit deve essere adattato al firmware bersaglio. Senza inventario, quindi, non sai né cosa correggere né cosa dichiarare escluso.

La scelta operativa è più semplice: oggi identifica le macchine che usano PXE, associa ogni macchina a un owner e apri le richieste ai vendor; nel frattempo disabilita il network boot dove è superfluo. Il take finale è questo: la sicurezza firmware non si governa con un bollettino salvato tra i preferiti, ma con una tabella che collega asset, versione, funzione e decisione. Se quei quattro campi esistono, la prossima advisory richiederà minuti di triage invece di ore di ricostruzione.