La falla EDK II porta l’avvio da rete al centro della sicurezza del firmware
CVE-2026-97631 riguarda un preciso percorso di avvio. Individuare le macchine esposte e il firmware del produttore conta più di un allarme indistinto su tutti i server.
Una vulnerabilità critica di EDK II può permettere l'esecuzione di codice durante l'avvio da rete, prima che parta il sistema operativo. Per un amministratore la prima domanda è quindi molto concreta: questa macchina utilizza davvero il percorso di avvio PXE interessato? La sola presenza di firmware UEFI non basta a dimostrare l'esposizione.
L'avviso TianoCore relativo a CVE-2026-97631, pubblicato il 22 ottobre e tornato al centro dell'attenzione questa settimana, descrive una corruzione della memoria nel driver PXE Base Code. Per sfruttarla, i messaggi di rete devono raggiungere una macchina mentre si avvia attraverso quel driver. La finestra d'attacco appartiene al firmware: non è un normale servizio applicativo esposto per tutta la giornata di funzionamento.
Il percorso di avvio cambia la valutazione
PXE consente a un computer di ottenere dalla rete le risorse necessarie all'avvio. È utile per installare, ripristinare e gestire gruppi di macchine senza raggiungerle una per una con un supporto d'installazione. Implica però che il codice incaricato di gestire il traffico funzioni prima delle protezioni abitualmente offerte dal sistema operativo installato.
Il problema riguarda la gestione dei messaggi di errore ICMP. Secondo l'avviso, un attaccante in grado di raggiungere il client durante l'avvio può provocarne il blocco; per eseguire codice scelto dall'attaccante occorre anche conoscere la specifica versione del firmware bersaglio. Sono condizioni importanti per stabilire le priorità. Non rendono innocua la falla, ma impediscono di tradurre un punteggio critico nell'affermazione che ogni server sia attaccabile allo stesso modo, da qualunque posizione.
La correzione collegata dall'avviso e il firmware effettivamente installato rappresentano dunque due passaggi differenti. Una modifica nel repository documenta il lavoro sul codice. Non dimostra che il produttore della scheda l'abbia già integrata, collaudata sulla propria piattaforma e distribuita per quel modello.
Prima l'inventario, poi la scelta operativa
Una risposta utile parte da modelli hardware, fornitori del firmware e procedure di installazione. Un gruppo di server che si avvia normalmente dai dischi locali potrebbe utilizzare la rete durante un ripristino. Anche quel percorso occasionale merita attenzione, pur non facendo parte della routine quotidiana.
Occorre quindi cercare indicazioni specifiche presso il produttore del sistema o del firmware e verificare se l'avvio da rete sia necessario. Disattivare una funzione inutilizzata può ridurre l'esposizione; eliminarla da una procedura indispensabile senza un'alternativa può invece interrompere installazione o recupero. La scelta dipende dall'ambiente reale, non da un consiglio indistinto per tutti i computer dotati di UEFI.
Per lo stesso motivo, un aggiornamento del sistema operativo non sostituisce il controllo del firmware. Il software caricato dopo l'avvio non rimpiazza il codice che ha già elaborato i pacchetti in quella fase precedente. Le normali protezioni restano utili, ma il loro ambito non va confuso con quello della vulnerabilità.
Una finestra breve, una manutenzione lunga
Il passaggio più complesso è la distribuzione. Un componente condiviso può essere presente in molte famiglie di prodotti, ciascuna con collaudi e cicli di assistenza differenti. L'hardware non più supportato potrebbe non ricevere lo stesso rimedio di un server attuale: proprio lì servono un inventario affidabile e una decisione esplicita sulle mitigazioni.
Il risultato pratico dovrebbe essere un elenco con una risposta per ogni sistema: percorso non interessato, aggiornamento confermato dal produttore oppure controllo temporaneo documentato. Il titolo critico richiama l'attenzione; quell'elenco la trasforma in una superficie d'attacco più piccola.
