UEFI, falla di 16 anni espone i server prima di Secure Boot

🛡️ Executive Summary

• Una vulnerabilità critica presente da 16 anni in TianoCore EDK II consente di eseguire codice prima del sistema operativo attraverso pacchetti ICMP durante l’avvio PXE.
• CVE-2026-97631 raggiunge CVSS 9,5: l’attacco non richiede autenticazione, ma necessita di un dispositivo vulnerabile in fase di avvio da rete e di una configurazione firmware compatibile.
• La correzione è stata integrata nel codice sorgente il 15 ottobre 2026, ma al 28 ottobre non risulta ancora inclusa in una versione stabile di EDK II. Non sono confermati attacchi reali.

Una vulnerabilità critica rimasta nascosta per 16 anni nel codice UEFI utilizzato da numerosi produttori hardware espone i server che effettuano l’avvio attraverso la rete. Identificata come CVE-2026-97631, la falla interessa il progetto open source TianoCore EDK II e permette a un aggressore di corrompere la memoria del firmware mediante pacchetti ICMP costruiti appositamente. Nelle condizioni necessarie allo sfruttamento, l’attacco può raggiungere l’esecuzione di codice durante la fase DXE, prima che Secure Boot abbia completato le verifiche di avvio del sistema operativo. Il problema riguarda soprattutto infrastrutture enterprise, data center e sistemi di provisioning che utilizzano PXE, mentre la diffusione del codice EDK II rende complessa l’identificazione dei singoli prodotti vulnerabili.

CVE-2026-97631: il buffer overflow nel firmware UEFI esiste dal 2010

La vulnerabilità CVE-2026-97631, classificata con punteggio CVSS 4.0 pari a 9,5, è stata individuata da Alex Matrosov di Anthropic e Dan Holmes-Mitra di Google nel componente NetworkPkg/UefiPxeBcDxe di TianoCore EDK II, una delle implementazioni di riferimento più diffuse per lo sviluppo dei firmware UEFI. Secondo l’advisory ufficiale GHSA-99cj-7hg9-mp4m pubblicato da TianoCore il 22 ottobre 2026, il problema riguarda il driver PXE Base Code, utilizzato dai sistemi che scaricano le immagini di avvio attraverso la rete anziché caricarle esclusivamente dai dischi locali. Durante questa procedura, il driver mantiene attivo un meccanismo di ricezione dei messaggi di errore ICMP, copiandone il contenuto in un campo di memoria denominato Mode.IcmpError, con dimensione fissa di 504 byte. Le routine responsabili della gestione dei messaggi IPv4 e IPv6 non applicano correttamente i limiti del buffer e utilizzano un calcolo errato degli offset durante la copia dei frammenti. Un messaggio sufficientemente grande può quindi scrivere dati oltre lo spazio assegnato, sovrascrivendo strutture adiacenti e alterando il funzionamento del firmware. Il codice difettoso risale al novembre 2010, circostanza che rende particolarmente significativo il ritardo nella scoperta: successive revisioni, controlli e attività di analisi del progetto non avevano individuato questa specifica condizione. Il precedente delle vulnerabilità PixieFail nello stack di rete UEFI aveva già mostrato quanto i componenti utilizzati prima del caricamento del sistema operativo possano esporre infrastrutture apparentemente protette.

Leggi anche: Bootkitty e LogoFAIL: nuovo livello di minaccia ai sistemi Linux UEFI

Un pacchetto ICMP può eseguire codice nel firmware prima dei controlli Secure Boot

La catena di sfruttamento descritta da TianoCore parte dalla possibilità di raggiungere l’indirizzo IP del sistema durante la breve finestra temporale in cui viene eseguito l’avvio PXE. Non sono necessarie credenziali di autenticazione, ma l’aggressore deve poter inviare un messaggio ICMP al dispositivo quando il driver vulnerabile è operativo. L’invio del pacchetto può provocare una corruzione della memoria sufficientemente grave da interrompere il processo di avvio, causando un denial of service che impedisce il provisioning o il ripristino del server. La seconda possibilità è più complessa e riguarda l’esecuzione arbitraria di codice: conoscendo la specifica build firmware e la disposizione delle strutture in memoria, un attaccante può tentare di costruire un evento contraffatto capace di far eseguire istruzioni durante la fase DXE, Driver Execution Environment, attraverso il meccanismo CoreSignalEvent(). L’esecuzione avverrebbe nel contesto privilegiato del firmware, prima del sistema operativo e delle relative difese. Il punto non è una violazione diretta degli algoritmi crittografici di Secure Boot, ma la possibilità di alterare il flusso di esecuzione prima che la catena di fiducia completi le proprie verifiche. Il codice introdotto attraverso questa vulnerabilità non è automaticamente persistente e normalmente si esaurisce con la singola esecuzione, ma potrebbe essere utilizzato per preparare ulteriori modifiche persistenti quando il firmware e la configurazione del sistema lo consentono. La minaccia si inserisce nello stesso perimetro di sicurezza già analizzato attraverso gli shim UEFI vulnerabili individuati da ESET, pur utilizzando un vettore differente.

AMI, Insyde, Phoenix e Project Mu: quali dispositivi potrebbero essere vulnerabili?

La diffusione di EDK II rappresenta il fattore che rende la vulnerabilità potenzialmente rilevante per un numero elevato di infrastrutture. Il progetto viene utilizzato come base di sviluppo da produttori di firmware e hardware, compresi AMI, Insyde e Phoenix, mentre componenti derivati sono presenti anche in Project Mu, la distribuzione EDK II rafforzata sviluppata nell’ecosistema Microsoft. Questo non significa che tutti i server o i computer dotati di UEFI siano vulnerabili: l’esposizione dipende dalla presenza effettiva del driver interessato, dalla versione del codice incorporato, dalla configurazione del firmware e dall’utilizzo dell’avvio PXE. Le piattaforme che effettuano normalmente il boot da disco locale senza attraversare il percorso vulnerabile non risultano esposte al vettore descritto dall’advisory. Intel ha dichiarato di non conoscere prodotti commerciali attualmente supportati direttamente interessati, precisando che i costruttori possono comunque integrare componenti EDK II nei propri firmware; Arm ha indicato che la vulnerabilità non riguarda direttamente il proprio portafoglio di prodotti. Il quadro rimane quindi incompleto sul piano delle singole piattaforme. Anche le distribuzioni Linux utilizzano implementazioni basate su EDK II per ambienti virtualizzati: il security tracker ufficiale di Debian segnala CVE-2026-97631 come vulnerabile nei rami Bookworm, Trixie, Forky e Sid. Questa informazione non implica che ogni macchina Debian sia esposta, perché occorre distinguere il sistema operativo dal firmware utilizzato dalla macchina fisica o virtuale. Per gli amministratori di data center è quindi necessario ricostruire l’intera catena di dipendenze, includendo firmware OEM, hypervisor, ambienti OVMF e sistemi di avvio automatizzato.

La patch è nel codice sorgente ma manca ancora una release stabile corretta

La gestione della vulnerabilità presenta un ulteriore problema: la correzione è diventata pubblica prima della divulgazione coordinata inizialmente prevista per gennaio 2027. Il 28 settembre un contributo presentato al progetto EDK II, riconducibile a un ingegnere AMI, aveva già descritto la falla e proposto una soluzione, rendendo disponibili informazioni sufficienti per comprenderne il funzionamento. Dopo una revisione del codice, la correzione è stata integrata nel ramo principale il 15 ottobre, attraverso il contributo identificato dal commit ufficiale 560ed9b5. La modifica introduce controlli sui limiti del buffer e corregge il calcolo degli offset nelle routine che gestiscono i messaggi ICMP IPv4 e IPv6, impedendo la scrittura oltre i 504 byte disponibili. Sono stati inoltre aggiunti test dedicati alla gestione dei frammenti e all’integrità delle strutture coinvolte. Al 28 ottobre 2026, tuttavia, l’advisory TianoCore continua a indicare l’assenza di una versione stabile corretta, mentre l’ultima release pubblica, edk2-stable202608, risale al 21 agosto e precede la modifica. Il codice sorgente corretto non coincide quindi con la disponibilità di un aggiornamento installabile per i server in produzione. I produttori dovranno integrare le modifiche, verificarne la compatibilità con le proprie piattaforme e distribuire firmware BIOS/UEFI aggiornati. Questa procedura può richiedere tempi differenti e diventare particolarmente problematica per sistemi non più supportati. Diversamente dalle vulnerabilità che richiedono la revoca di certificati o chiavi Secure Boot, il problema può essere corretto intervenendo sul codice del driver, senza imporre necessariamente una revisione dell’intera infrastruttura crittografica di avvio.

Continua con:

N-central RCE sotto attacco, F5 BIG-IP riceve un rootkit e Cisco UCS perde Secure Boot

Eclypsium rivela backdoor firmata nei dispositivi Framework: rischio bootkit su 200.000 macchine

Data center e server PXE devono verificare firmware e segmentazione delle reti

La priorità operativa riguarda i sistemi che utilizzano PXE per provisioning, installazione automatizzata, ripristino o avvio di infrastrutture centralizzate. Gli amministratori devono identificare le piattaforme che incorporano il driver vulnerabile, verificare la disponibilità di aggiornamenti presso i produttori e ridurre la possibilità che sistemi non autorizzati raggiungano i dispositivi durante il processo di avvio. Disabilitare PXE dove non necessario rappresenta una mitigazione concreta, perché impedisce di attraversare il percorso software nel quale si trova la vulnerabilità. Negli ambienti dove il network boot è indispensabile, la misura più importante consiste nell’isolare le reti di provisioning, controllare il traffico diretto ai client e limitare le comunicazioni ICMP provenienti da segmenti non attendibili, senza compromettere le funzionalità necessarie all’avvio. Secure Boot e TPM devono rimanere attivi per garantire le altre proprietà di sicurezza della piattaforma, ma non costituiscono una protezione sufficiente contro un’esecuzione di codice ottenuta prima delle relative verifiche. Al momento non risultano attacchi reali confermati associati a CVE-2026-97631, né la sua presenza nel catalogo CISA KEV aggiornato al 27 ottobre. La disponibilità pubblica del codice di correzione aumenta comunque la possibilità che ricercatori e attaccanti sviluppino strumenti capaci di verificare o sfruttare il difetto. Per aziende, fornitori cloud e amministrazioni pubbliche italiane, il rischio richiede soprattutto attenzione ai sistemi che utilizzano firmware condivisi e processi di avvio automatizzati, dove una vulnerabilità introdotta sedici anni prima può sopravvivere a più generazioni hardware e software. La protezione della catena di avvio dipende anche dalla manutenzione del codice più antico, non soltanto dalle nuove funzionalità di sicurezza introdotte dai produttori.