CVE-2026-97631: il boot di rete è un perimetro dimenticato

Puoi aggiornare Linux, tenere sotto controllo i servizi, segmentare la rete, applicare policy rigorose e verificare ogni giorno che tutto funzioni. Poi arriva il momento in cui quella macchina deve accendersi. E scopri che esiste un pezzo di infrastruttura che raramente compare nei report di sicurezza: il percorso con cui il server arriva a caricare il sistema operativo. Un percorso che, in certi ambienti, passa dalla rete prima ancora che esista un kernel a difenderlo.

La vulnerabilità CVE-2026-97631, divulgata da TianoCore il 22 ottobre 2026, è un esempio particolarmente concreto. Non perché dimostri che ogni server del pianeta sia compromesso, ma perché mette in evidenza una dipendenza operativa che spesso diamo per scontata: il firmware UEFI e il suo codice di avvio PXE. Il problema è grave, ha un punteggio CVSS v4 di 9,5, ma capirlo richiede qualcosa di più utile di un titolo allarmistico: ricostruire quando il codice vulnerabile viene effettivamente eseguito.

Il problema non è Linux. È quello che succede prima

EDK II è una base open source utilizzata per costruire firmware UEFI. Tra i suoi componenti c’è NetworkPkg/UefiPxeBcDxe, il driver che gestisce parte dell’avvio tramite PXE, cioè il caricamento di un ambiente di boot attraverso la rete. In quel momento il firmware deve gestire anche messaggi di errore ICMP, sia IPv4 sia IPv6.

Secondo l’advisory ufficiale TianoCore GHSA-99cj-7hg9-mp4m, il driver copia questi messaggi in un campo di memoria fisso da 504 byte, Mode.IcmpError. Il controllo delle dimensioni è errato: un messaggio più lungo può provocare una scrittura oltre i limiti del buffer. Non stiamo parlando di una configurazione PHP sbagliata o di un servizio dimenticato su una porta TCP. La corruzione avviene nella fase DXE del firmware, mentre il sistema operativo non è ancora partito.

L’effetto più immediato può essere il blocco dell’avvio. In condizioni più specifiche, con conoscenza della build firmware e della disposizione della memoria, la vulnerabilità può consentire esecuzione di codice prima che Secure Boot o il measured boot abbiano completato le verifiche sui componenti del sistema operativo. È una differenza enorme rispetto a un normale processo compromesso dopo il login: le difese che osserviamo quotidianamente non sono ancora entrate in scena.

Un CVSS 9,5 non è il censimento dei server esposti

Il codice EDK II è ampiamente riutilizzato nell’ecosistema UEFI. Questo rende la falla importante per la filiera, ma non autorizza a concludere che qualunque computer acceso sia attaccabile da Internet. Per arrivare a questo particolare difetto servono condizioni precise, e confondere la diffusione del codice con l’esposizione del singolo dispositivo produce una valutazione del rischio tanto rumorosa quanto poco operativa.

• Firmware interessato: la macchina deve includere una versione vulnerabile del driver PXE; non basta sapere che usa UEFI.
• Percorso di avvio: il componente deve essere effettivamente utilizzato durante un boot PXE, non semplicemente esistere nel codice sorgente di riferimento.
• Raggiungibilità: l’attaccante deve riuscire a far arrivare il messaggio ICMP al client durante quella finestra di avvio. Non è una porta applicativa permanentemente esposta.
• Impatto: un blocco del boot e un’esecuzione di codice affidabile non hanno la stessa difficoltà. Per la seconda l’advisory descrive condizioni più stringenti, legate alla build firmware.

Questo non riduce la gravità del difetto. La rende misurabile. Un data center che effettua provisioning PXE su segmenti condivisi ha un profilo di rischio diverso da una macchina che avvia esclusivamente da disco, con boot di rete disabilitato. La domanda utile non è “quanti server usano UEFI?”, ma “quali dei nostri server attraversano davvero questo percorso e da quali reti possono ricevere traffico mentre lo fanno?”.

Una superficie d’attacco che non compare nell’inventario non è una superficie d’attacco inesistente. È soltanto una superficie che abbiamo deciso di non misurare.

Il firmware è una dipendenza. E le dipendenze hanno una filiera

Qui c’è un secondo problema, meno spettacolare dell’overflow ma più interessante per chi gestisce sistemi: una correzione nel repository non equivale a una macchina aggiornata. La pull request upstream #13302 corregge la gestione del buffer. Alla data del 28 ottobre 2026, tuttavia, l’advisory TianoCore indica ancora che non esiste una versione stabile corretta elencata tra le patched versions. Un produttore deve integrare la modifica, adattarla, testarla sul proprio hardware e distribuire un aggiornamento firmware supportato.

È un passaggio che chi sviluppa software conosce bene: il codice sorgente aggiornato, il pacchetto distribuito e il componente realmente in esecuzione sono tre stati differenti. Lo stesso principio emerge quando un’applicazione .NET incorpora il proprio runtime: aggiornare ciò che sta intorno non sostituisce la verifica della dipendenza che viene caricata davvero. Nel firmware, però, il processo è ancora meno visibile: spesso non c’è un normale package manager a raccontarci la storia.

Ecco perché una risposta basata solo sul numero di CVE aperte non basta. Occorre sapere chi ha costruito il firmware, quale versione è installata, quali moduli sono inclusi e come si verifica che un aggiornamento sia arrivato sui dispositivi. Il controllo della filiera non si esaurisce nel firmare un artefatto: come accade anche nei confini tra container e kernel, la garanzia vale soltanto se abbiamo individuato il componente a cui si applica.

Secure Boot non è una bacchetta magica

Secure Boot ha uno scopo preciso: verificare la fiducia dei componenti previsti nel processo di avvio. Non trasforma automaticamente ogni riga di codice firmware eseguita prima di quelle verifiche in codice sicuro. Se un driver già in esecuzione contiene un errore di gestione della memoria, la firma del sistema operativo non elimina quell’errore. Non è una ragione per disabilitare Secure Boot: è una ragione per non attribuirgli capacità che non possiede.

L’advisory descrive una possibile esecuzione nella fase DXE, prima delle verifiche sul sistema operativo. Questo non dimostra che ogni attacco possa installare persistenza o aggirare ogni protezione su ogni piattaforma. Significa che il modello di fiducia va letto nella sua sequenza reale: firmware, inizializzazione, driver, avvio, verifiche e infine sistema operativo. Se saltiamo i primi passaggi perché non compaiono nella dashboard dell’EDR, stiamo semplificando il diagramma, non proteggendo la macchina.

Cosa controllare davvero, senza aspettare un exploit

1. Inventario del percorso di boot

Separare i sistemi che fanno provisioning PXE da quelli che avviano da storage locale. Registrare modello hardware, versione firmware, configurazione di boot e responsabile dell’aggiornamento. Non assumere che un’impostazione di default sia rimasta invariata nel tempo. In ambienti con molti server, l’inventario deve poter rispondere anche alla domanda opposta: quali macchine potrebbero ancora tentare un avvio di rete in caso di errore del disco o cambio dell’ordine di boot?

2. Ridurre la raggiungibilità della fase vulnerabile

Dove PXE non serve, valutarne la disabilitazione nella configurazione firmware. Dove serve, limitare la rete di provisioning e il traffico che può raggiungere i client durante l’avvio, senza immaginare che una VLAN sia automaticamente un confine di sicurezza perfetto. L’advisory non propone un workaround universale: queste sono misure di riduzione della superficie, non una patch sostitutiva.

3. Tracciare gli aggiornamenti fino all’hardware

Monitorare gli avvisi del produttore del server o della scheda madre, non soltanto il repository EDK II. Prima di pianificare un aggiornamento firmware servono compatibilità, finestra di manutenzione, rollback e verifica della versione effettivamente installata. Se il vendor non ha ancora pubblicato un firmware corretto, documentare l’esposizione residua e le mitigazioni temporanee, anziché segnare il problema come risolto perché una pull request è stata chiusa.

4. Osservare gli avvii falliti, non solo i servizi attivi

Un boot PXE che si blocca o si ripete può avere molte cause innocue, ma in un contesto di vulnerabilità pre-boot merita correlazione con i log di provisioning e con il traffico di rete disponibile. Non è una firma affidabile di compromissione, e l’assenza di errori non dimostra sicurezza. È semplicemente un punto di osservazione che non andrebbe lasciato fuori dal monitoraggio operativo.

La lezione non è comprare un altro strumento

CVE-2026-97631 non ci dice che ogni server sia compromesso e, al 28 ottobre 2026, le fonti pubbliche consultate non dimostrano una campagna di sfruttamento generalizzata. Ci dice qualcosa di più concreto: la superficie d’attacco di un sistema non coincide con i processi che vediamo quando il sistema è già acceso. Comprende anche il codice che lo porta a quello stato, la rete che attraversa e la catena di soggetti che distribuisce gli aggiornamenti.

Un’organizzazione può avere ottimi strumenti di sicurezza e continuare a non sapere come si avviano davvero le proprie macchine. Ecco il paradosso: aggiungiamo controlli sopra controlli, poi dimentichiamo di disegnare il processo su cui tutti quei controlli poggiano. Prima di chiederci quale prodotto ci proteggerà dal prossimo CVE, forse vale la pena rispondere a una domanda meno appariscente: chi è responsabile del primo codice che il nostro server esegue?