Un server può avere sistema operativo, antivirus e applicazioni aggiornati, ma restare esposto nel minuto in cui cerca di avviarsi dalla rete. CVE-2026-97631 interessa proprio quella finestra: il driver PXE di EDK II può elaborare un messaggio ICMP oltre i limiti del buffer ed eseguire codice prima che il sistema operativo abbia caricato le proprie difese.

Per una PMI la decisione utile non è chiedersi se «tutti i server del mondo» siano vulnerabili. Serve capire quali macchine usano davvero il network boot, quale firmware montano, chi può raggiungerle durante l’avvio e chi ha la responsabilità di applicare l’aggiornamento. Questa guida trasforma l’allerta in un inventario verificabile, una mitigazione temporanea e un piano di patch.

Il rischio nasce prima del sistema operativo

L’advisory ufficiale di TianoCore, pubblicato il 22 ottobre 2026, descrive una vulnerabilità critica nel pacchetto NetworkPkg di EDK II. L’identificativo è CVE-2026-97631 e il punteggio CVSS 4.0 indicato dal progetto è 9,5 su 10.

Il componente coinvolto è NetworkPkg/UefiPxeBcDxe, usato per il boot PXE su IPv4 e IPv6. Durante il network boot il driver mantiene aperta una richiesta per ricevere errori ICMP. I dati ricevuti vengono copiati nel campo fisso Mode.IcmpError, lungo 504 byte. La gestione errata dei limiti e degli offset permette a un messaggio più grande di scrivere oltre il campo previsto.

Gli effetti documentati sono due. Il primo è un arresto del processo di boot, quindi un problema di disponibilità. Il secondo, più grave, è l’esecuzione di byte controllati dall’attaccante nella fase DXE, con privilegi elevati e prima dell’avvio del sistema operativo. Per arrivare all’esecuzione di codice l’attaccante deve conoscere la build del firmware bersaglio; non esiste quindi un unico payload universale valido per qualsiasi server.

Il punto operativo è questo: Secure Boot, measured boot, EDR e controlli installati nel sistema operativo non possono prevenire un’esecuzione che avviene prima del loro intervento. Devono rimanere attivi, perché proteggono altri passaggi della catena di avvio, ma non vanno registrati come mitigazione sufficiente per questa specifica vulnerabilità.

Chi è davvero esposto

La presenza di EDK II nell’ecosistema non basta a dichiarare vulnerabile un prodotto. Firmware diversi incorporano versioni e componenti differenti; inoltre l’attacco descritto richiede che la macchina stia eseguendo il boot PXE. L’analisi tecnica di Ars Technica evidenzia proprio l’assenza, al momento, di una lista completa di modelli e versioni colpite.

Un server entra nel perimetro di verifica quando ricorrono queste condizioni:

  • il firmware include il driver PXE vulnerabile derivato da EDK II;
  • il network boot su IPv4 o IPv6 è abilitato o presente nell’ordine di avvio;
  • durante il boot la scheda di rete può ricevere messaggi ICMP da una rete raggiungibile dall’attaccante;
  • non è ancora disponibile, o non è ancora installato, un firmware corretto dal produttore del sistema.

La finestra di esposizione coincide con la fase PXE, non con l’intera operatività del server. Questo riduce le occasioni di attacco, ma non giustifica l’inazione: un attaccante già presente nella rete, un insider o un sistema compromesso nella VLAN di provisioning può attendere un riavvio pianificato, un ripristino o un nuovo deployment.

Al contrario, un computer che esegue il boot solo dal disco locale e non carica il componente PXE non presenta il percorso d’attacco descritto dall’advisory. Va comunque verificata la configurazione reale: «non usiamo PXE» non equivale a «PXE è disabilitato nel firmware». In molti ambienti il network boot rimane nell’ordine di avvio per abitudine, per un vecchio progetto di provisioning o come opzione di recovery mai rimossa.

Inventario: cosa raccogliere oggi

Il primo deliverable non è un aggiornamento installato alla cieca, ma una tabella firmata da chi gestisce l’infrastruttura. Ogni riga deve rappresentare un server fisico, un appliance o un dispositivo che può avviarsi dalla rete. Per ciascun asset conviene registrare:

  • proprietario del servizio e referente tecnico;
  • produttore, modello, numero di serie o service tag;
  • versione e data del BIOS/UEFI, rilevate dalla console di gestione o dal sistema;
  • stato del PXE per IPv4 e IPv6 e posizione del network boot nell’ordine di avvio;
  • interfaccia usata per il provisioning e VLAN associata;
  • presenza di BMC, iDRAC, iLO o altra gestione out-of-band e relativo perimetro di accesso;
  • stato del supporto del produttore e URL del bollettino di sicurezza applicabile;
  • finestra di manutenzione, possibilità di rollback e dipendenze del servizio.

Non basta esportare il modello hardware. La versione del firmware è la chiave per collegare l’asset a un futuro bollettino del vendor. Conserva anche una prova: screenshot della configurazione PXE, export della console di gestione o output dello strumento di inventario. La prova evita che una macchina venga classificata come sicura sulla base di una risposta orale.

Per VPS, cloud pubblico e hosting gestito, l’azienda cliente di solito non controlla il firmware dell’host fisico. In questo caso la riga dell’inventario deve contenere il provider, il tipo di servizio e il ticket con cui sono state poste tre domande precise: il sistema usa il componente coinvolto, il PXE è esposto nel modello operativo e qual è il piano di aggiornamento. Una risposta generica come «l’infrastruttura è protetta» non chiude il rischio.

Mitigazione temporanea senza falsi positivi

Se il PXE non serve, la mitigazione più diretta è disabilitare il network boot nel firmware e rimuoverlo dall’ordine di avvio. La modifica va testata su un sistema pilota e documentata: alcuni processi di recovery, installazione automatica o sostituzione bare-metal possono dipendere da quella funzione anche se non viene usata ogni giorno.

Se il PXE serve, va trattata la rete di provisioning come un ambiente amministrativo separato, non come una comodità della LAN aziendale. Le misure provvisorie includono:

  • isolare server PXE, DHCP, TFTP e client in una VLAN dedicata;
  • limitare routing e accessi alla sola infrastruttura necessaria al provisioning;
  • impedire ai segmenti utente, guest e IoT di raggiungere la rete di boot;
  • ridurre il numero di sistemi autorizzati ad amministrare BMC e console remote;
  • rimuovere il PXE dall’ordine predefinito quando può essere attivato solo per una manutenzione controllata;
  • registrare riavvii inattesi, errori di provisioning e variazioni della configurazione firmware.

Bloccare indiscriminatamente tutto l’ICMP non è una strategia di sicurezza completa: può interrompere diagnosi e funzioni di rete, mentre il vero obiettivo è impedire che sorgenti non autorizzate raggiungano il client durante il boot. La regola va progettata sul traffico e sulle topologie effettive, poi provata con il team che gestisce rete e provisioning.

Un backup dei dati rimane necessario, ma non corregge il firmware. Anche reinstallare il sistema operativo non dimostra che la catena di avvio sia integra. Questo è lo stesso principio applicato alle patch applicative: nella guida su come preparare WordPress a una patch PHP critica la priorità è associare componente, versione, test e rollback; qui il componente si trova semplicemente un livello più in basso.

Un piano di patch senza blackout

Il repository EDK II mostra una correzione del buffer overflow, con controlli sui limiti e sugli offset per IPv4 e IPv6. Per chi amministra server, però, una modifica nel progetto sorgente non equivale a un firmware pronto da installare. Il pacchetto utilizzabile deve arrivare dal produttore del server, della scheda madre o dell’appliance, con firma, note di rilascio e istruzioni per quel modello.

La sequenza consigliata è:

  1. Conferma. Apri il bollettino del produttore e collega modelli, versioni installate e versioni corrette. Se il bollettino non esiste, apri un ticket e conserva la risposta.
  2. Pilota. Scegli una macchina non critica ma rappresentativa per controller, schede di rete, storage e configurazione Secure Boot.
  3. Preparazione. Verifica backup della configurazione, accesso alla console out-of-band, alimentazione stabile, procedura di recovery e compatibilità con hypervisor o sistema operativo.
  4. Aggiornamento. Usa solo il pacchetto e il canale ufficiali del vendor. Registra versione precedente, versione nuova, orario e operatore.
  5. Test. Controlla boot locale, eventuale boot PXE, rete, storage, virtualizzazione, Secure Boot, TPM e log della console.
  6. Distribuzione. Procedi per gruppi piccoli, con una pausa sufficiente a osservare errori e con un criterio esplicito di stop.
  7. Chiusura. Aggiorna l’inventario e allega l’evidenza della versione installata. Un ticket chiuso senza verifica tecnica non è una patch verificata.

Per cluster e servizi ridondati, sposta prima il carico, aggiorna un nodo e verifica che rientri correttamente nel pool. Per un singolo server che ospita più servizi, la finestra deve includere tempo per un eventuale recovery del firmware, non soltanto il riavvio ordinario. Se il vendor non fornisce una correzione perché il prodotto è fuori supporto, la decisione diventa di rischio: isolamento rafforzato, PXE disabilitato e piano di sostituzione con una data, non un generico «monitorare».

Priorità per PMI, hosting e WordPress

La vulnerabilità non è un problema specifico di WordPress, ma può interessare il server fisico che ospita sito, database, backup o ambiente di staging. La responsabilità cambia in base al servizio acquistato:

  • hosting condiviso o managed WordPress: il provider gestisce il firmware; il cliente deve chiedere conferma e monitorare lo stato del ticket;
  • VPS o cloud: il provider gestisce l’host fisico, mentre il cliente continua a proteggere sistema guest e applicazioni;
  • server dedicato in housing: il contratto stabilisce chi applica il firmware; non va presunto che sia il datacenter;
  • server in ufficio, NAS e appliance: l’azienda o il partner IT deve verificare modello, firmware, PXE e supporto del produttore.

La priorità più alta va a macchine con PXE attivo, rete di provisioning poco segmentata, firmware non inventariato e accesso amministrativo distribuito. Subito dopo vengono i sistemi che usano PXE in una rete isolata ma non hanno ancora una risposta del vendor. In coda possono stare i dispositivi con network boot disabilitato e configurazione provata, pur mantenendo il controllo sui bollettini.

La gestione degli accessi conta quanto la patch: credenziali di BMC condivise, VPN di fornitori ancora attive e console esposte ampliano le possibilità di raggiungere il percorso di boot. La procedura per revocare gli accessi remoti dei fornitori offre un modello riutilizzabile: censire l’accesso, assegnare un proprietario, ridurre il privilegio e fissare una scadenza.

Checklist di chiusura operativa

Prima di dichiarare gestito CVE-2026-97631, il responsabile IT dovrebbe poter rispondere con un’evidenza a queste domande:

  • quali asset fisici o appliance sono nel perimetro;
  • quali versioni BIOS/UEFI risultano installate;
  • su quali macchine PXE IPv4 o IPv6 è realmente abilitato;
  • quali reti possono raggiungere i client durante il boot;
  • chi amministra BMC e console out-of-band;
  • quale vendor ha confermato impatto o non impatto;
  • quale firmware corretto è disponibile per ogni modello;
  • quale macchina farà da pilota e quali test dovrà superare;
  • come si recupera un aggiornamento firmware fallito;
  • quali sistemi fuori supporto devono essere isolati o sostituiti.

La scelta pratica è semplice: disabilita PXE dove non serve; dove serve, separalo dalla rete ordinaria e pretendi una risposta puntuale dal produttore. Poi applica il firmware solo dopo un test rappresentativo. CVE-2026-97631 non richiede panico né una scansione generica del sito web: richiede inventario hardware, controllo della rete di boot e responsabilità chiare.

Fonti

Approfondimenti