Un errore su GitHub ha reso pubblica la patch di una falla UEFI da 9.5 su 10

Nota metodologica: Questo articolo si basa su due fonti di news tecniche, hwupgrade.it e cybersecuritynews.com, con possibile derivazione da fonte comune. Non è disponibile un advisory strutturato da ZDI, GHSL o CERT/CC dedicato a questa CVE. Le affermazioni su impatti potenziali usano il condizionale quando non confermate da fonti primarie.

Il 15 ottobre 2026 la PR 13302 è stata mergeata nel ramo master pubblico di EDK II, il framework open-source del firmware UEFI. La pull request correggeva CVE-2026-97631, vulnerabilità con CVSS 9.5 che permette esecuzione di codice in fase DXE, prima di Secure Boot. L'embargo coordinato era previsto per gennaio 2027. La pubblicazione prematura ha reso il codice corretto accessibile prima dell'advisory ufficiale.

I fatti verificati: timeline e meccanismo

La vulnerabilità CVE-2026-97631 è stata scoperta da Alex Matrosov (Anthropic) e Dan Holmes-Mitra (Google). Il driver UefiPxeBcDxe gestisce il boot via rete PXE; il campo Mode.IcmpError è bufferizzato a 504 byte. I gestori PxeBcIcmpErrorDpcHandle (IPv4) e PxeBcIcmp6ErrorDpcHandle (IPv6) copiano messaggi ICMP di errore senza controlli di boundary, avanzando il puntatore per lunghezza cumulativa invece che per singolo frammento.

L'attaccante invia unicast ICMP error message all'IP del client durante PXE boot. Il payload viene eseguito in fase DXE con privilegi ring 0, prima che Secure Boot o measured boot verifichino componenti del sistema operativo. Il payload diretto non ha persistenza, ma secondo le fonti può aprire a payload persistenti successivi.

"Un buffer overflow nel driver PXE Base Code di EDK II [...] apre a un attaccante non autenticato la strada verso l'esecuzione di codice in fase DXE, prima che Secure Boot o il measured boot abbiano verificato o misurato qualsiasi componente del sistema operativo"
— Andrea Bai, hwupgrade.it

La PR 13302, aperta da mdkinney il 14 ottobre 2026, aggiunge controlli boundary, corregge pointer math nei gestori ICMP IPv4/IPv6, tronca messaggi sovradimensionati, azzera buffer con ZeroMem() e include unit test. Il merge nel ramo master è avvenuto il 15 ottobre.

L'errore di disclosure: embargo violato per mistake

L'advisory TianoCore è stato pubblicato il 22 ottobre 2026, sette giorni dopo il merge della PR. Il 27 ottobre jkmathews, maintainer del progetto, ha commentato la PR 13302 confermando che "l'embargo è stato violato per errore, con la pull request creata allo scoperto".

La fonte hwupgrade.it cita una PR di AMI come elemento correlato, ma non conferma che corrisponda alla PR 13302. cybersecuritynews.com non menziona AMI nella descrizione della pull request. L'identità esatta del vendor che ha aperto la PR rimane non verificata nel dossier.

Analisi: cosa il codice pubblico rende possibile

Il codice corretto pubblico su GitHub consente a chi analizza il diff di ricostruire la vulnerabilità. La correzione mostra esattamente dove i controlli mancavano: nei gestori ICMP di IPv4 e IPv6, nel calcolo degli offset, nel troncamento dei messaggi. Questa visibilità è conseguenza diretta della pubblicazione prematura, non inferenza su attività di attaccanti.

HD Moore, citato da hwupgrade.it via Ars Technica, ha descritto l'impatto: "Un attaccante intenzionato a compromettere un endpoint o un server vicino potrebbe usare questo bug per dirottare il flusso del programma in un punto in cui il processo di avvio ha ancora accesso a componenti sensibili, come il TPM dell'endpoint".

Cosa non sappiamo

Le fonti disponibili non forniscono: conteggio di server o dispositivi effettivamente vulnerabili; elenco completo prodotti OEM con build raggiungibili; stato patch vendor firmware (AMI, Insyde, Phoenix, Microsoft Project Mu); evidenza di exploit in-the-wild; dettaglio completo del CVSS vector; conferma che la PR di AMI citata da hwupgrade.it corrisponda alla PR 13302; data esatta di scoperta originale.

Cosa fare adesso

Le azioni seguenti sono dedotte dall'analisi dei meccanismi tecnici documentati, non presentate come raccomandazioni ufficiali dai vendor:

• Verificare se PXE boot è attivo nei sistemi gestiti: la vulnerabilità richiede questa condizione per essere esponibile
• Valutare la necessità di PXE boot dove attivo ma non funzionalmente richiesto: la rimozione del vettore riduce la superficie d'attacco
• Monitorare aggiornamenti edk2 nelle distribuzioni Linux: Debian ha classificato edk2 come vulnerabile in bookworm, trixie e sid; la versione unstable risulta ancora senza correzione
• Attendere advisory specifici dai vendor firmware per implementazioni basate su EDK II: al momento del report, nessuna fonte riporta advisory da AMI, Insyde, Phoenix o Microsoft Project Mu

Intel ha dichiarato che nessun suo prodotto commerciale sotto supporto è direttamente coinvolto. Arm ha classificato la CVE come non direttamente applicabile al proprio portafoglio. Le dichiarazioni limitano il perimetro dell'impatto ma non escludono che implementazioni di terze parti basate su EDK II siano vulnerabili.

Chiusura editoriale

La violazione dell'embargo per CVE-2026-97631 non è il primo caso di disclosure coordinata fallita nell'ecosistema firmware, ma la sua gravità è amplificata dalla severità della vulnerabilità e dalla visibilità del repository GitHub. Il codice corretto è pubblico da settimane; l'advisory ufficiale è arrivato dopo. Il divario tra disponibilità upstream e distribuzione effettiva misura la fragilità della supply chain firmware, non la competenza dei singoli maintainer.

Il commento di jkmathews — "la cosa va evitata" — è ammissione senza attenuanti. Resta da verificare quanti vendor downstream abbiano integrato la correzione, e quanti amministratori siano in grado di applicarla senza advisory specifici. La domanda non è se la disclosure coordinata possa fallire, ma cosa succede quando il codice parla prima del comunicato.

Fonti: hwupgrade.it; cybersecuritynews.com; shattered.io; tech-insider.org; cryptika.com. Nota: hwupgrade.it e cybersecuritynews.com potrebbero derivare da fonte comune; non è disponibile advisory strutturato ZDI/GHSL/CERT dedicato.

Fonti

• hwupgrade.it
• shattered.io
• tech-insider.org
• cybersecuritynews.com
• cryptika.com