De kwetsbaarheid CVE-2026-97631 is een kritieke buffer overflow (ernstscore 9,5/10) in de TianoCore EDK2-codebase, die door de meeste serverleveranciers en cloudproviders wordt gebruikt voor hun UEFI-firmware. De fout bevindt zich in de PXE-Base Code driver en stelt aanvallers met lokale netwerktoegang in staat om kwaadaardige code in 'ring 0' uit te voeren voordat beveiligingsmechanismen zoals Secure Boot en TPM actief worden.
Belangrijke details uit het artikel:
- Premature onthulling: De kwetsbaarheid werd voortijdig openbaar gemaakt via een pull request van AMI, waardoor het voor hackers eenvoudiger is om exploits te bouwen.
- Technische werking: Door een fout in het geheugenbeheer van de ICMP-component kunnen aanvallers gegevens voorbij een limiet van 504 bytes schrijven, wat leidt tot corruptie van de UEFI-module.
- Impact: Alleen organisaties die systemen opstarten via lokale netwerken (PXE-boot) lopen risico; thuisgebruikers zijn niet getroffen.
- Vendor reacties: Intel en Arm claimen dat hun commerciële producten niet direct getroffen zijn, hoewel zij wel gebruikmaken van EDK2-referentiecode.
Advies: Betrokken partijen wordt aangeraden om netwerk-bootmogelijkheden uit te schakelen en contact op te nemen met fabrikanten voor firmware-updates.
Code-uitvoeringsfout in UEFI-firmware treft de meeste servers op aarde
Beveiligingsexperts wereldwijd worden geconfronteerd met de taak om te reageren op een nieuwe, onhandig onthulde kwetsbaarheid voor code-uitvoering. Deze keer gaat het om boot-time firmware die wordt gebruikt door de meeste serverleveranciers en datacenters ter wereld.
De kwetsbaarheid, met een ernstscore van 9,5 uit 10, bevindt zich in TianoCore EDK II, een open-source codebase die hardwarefabrikanten en cloudproviders gebruiken om de UEFI-firmware te maken die draait tijdens de opstartsequentie. Vorig jaar noemde een vertegenwoordiger van het UEFI Forum EDK2 de "vooraanstaande oplossing/implementatie van de UEFI-specificaties." Vrijwel alle UEFI-leveranciers (soms nog IBV's of independent BIOS vendors genoemd), waaronder AMI, Insyde en Phoenix, maken uitgebreid gebruik van deze referentiecode. Ook Project Mu, de verharde EDK2-fork van Microsoft, maakte gebruik van de code die het kwetsbare component bevat.
De kwetsbaarheid, geregistreerd als CVE-2026-97631, is een fout in het geheugenbeheer van een ICMP-component. Aanvallers kunnen dit exploiteren om kwaadaardige code uit te voeren voordat het besturingssysteem en de firmware beveiligingen zoals Secure Boot kunnen implementeren. Secure Boot stelt normaal gesproken een 'keten van vertrouwen' (chain of trust) vast voor alle code die tijdens het opstarten wordt geladen, inclusief de Trusted Platform Module (TPM). Hoewel de uiteindelijke payloads die via CVE-2026-97631 worden afgeleverd geen persistentie hebben — wat betekent dat ze slechts één keer worden uitgevoerd — kunnen ze aanvallers een grote opening bieden om andere payloads te installeren die telkens opnieuw in een vroeg stadium van het opstartproces draaien.
Een voortijdige onthulling
De partijen die CVE-2026-97631 ontdekten — Alex Matrosov van Anthropic en Dan Holmes van Google — hadden afgesproken de kwetsbaarheid geheim te houden tot een gecoördineerde openbaarmaking die gepland stond voor januari. AMI, een fabrikant van moederborden en andere hardware, publiceerde echter vorige maand een pull request waarin de kwetsbaarheid werd gedetailleerd en een codefix was opgenomen. Zodra deze post ter kennis kwam van de ontdekkers, publiceerden leden van het TianoCore-project vorige week een openbaar advies.
Nu de patchcode publiekelijk beschikbaar is, zal het voor geavanceerde hackers triviaal zijn om te leren hoe de kwetsbaarheid wordt geactiveerd en om werkende exploits te bouwen. De urgentie wordt verder vergroot door het feit dat het patchen van UEFI-codekwetsbaarheden in miljoenen apparaten, verkocht en gebruikt door duizenden hardwarefabrikanten en cloudproviders, omslachtig en tijdrovend is. De melding van deze kwetsbaarheid komt zes dagen na een andere mislukte onthulling, waarbij het ging om een kritieke code-uitvoeringskwetsbaarheid in de programmeertaal PHP.
HD Moore, maker van Metasploit en chief research officer bij beveiligingsbedrijf Dragos, verklaart: "Deze kwetsbaarheid in de ICMP-parser van de EDK2-netwerkstack is interessant vanwege de manier waarop het de keten van vertrouwen en het bredere ecosysteem beïnvloedt. Een aanvaller die een nabijgelegen endpoint of server wil compromitteren, zou deze bug kunnen gebruiken om de programmaflow te kapen op een punt waar het opstartproces nog toegang heeft tot gevoelige componenten, zoals de TPM van het endpoint. Dit zou kunnen worden gebruikt om schijfversleuteling te doorbreken in gevallen waarin een aanvaller kortstondig netwerktoegang heeft (en het zou nog gemakkelijker zijn in een scenario van diefstal)."
Technische werking
CVE-2026-97631 is een 16 jaar oude buffer overflow in de PXE-Base Code driver (NetworkPkg/UefiPxeBcDxe). Deze driver is verantwoordelijk voor het mogelijk maken van het opstarten van servers, opslagapparatuur en andere apparaten met code die is gedownload van een lokaal netwerk. Tijdens dit proces — bekend als de pre-execution environment boot — gebruikt de driver een netwerklistener om te monitoren op ICMP-fouten. Omdat de driver geen limiet van 504 bytes afdwingt voor het kopiëren van het geheugen, kunnen aangrenzende gegevens worden overschreven. Een kwaadaardige insider of een hacker die toegang heeft gekregen tot een lokaal netwerk, kan een foutmelding sturen die code toevoegt voorbij deze limiet. De IUEFI-module die op de CPU draait, raakt hierdoor corrupt.
Het officiële advies stelt het als volgt:
Tijdens netwerkboot houdt de PXE Base Code driver (NetworkPkg/UefiPxeBcDxe) een ontvangstverzoek open voor ICMP-foutmeldingen en kopieert elke ontvangen melding naar het vaste veld van 504 bytes Mode.IcmpError van zijn private contextstructuur. De afhandeling van de grenzen van de kopieerlus is onjuist in zowel de IPv4- als de IPv6-handlers (PxeBcIcmpErrorDpcHandle en PxeBcIcmp6ErrorDpcHandle): voor een bericht langer dan 504 bytes worden er nog steeds bytes naar het veld gekopieerd, en de bestemmingspointer wordt gevorderd met de cumulatieve lengte in plaats van de lengte per fragment, waardoor een te groot bericht bytes die door de aanvaller worden beheerd, voorbij het veld schrijft. Niets eerder in het ontvangstpad beperkt de berichtlengte.
De kwaadaardige fout kan worden verzonden via een eenvoudige unicast vanaf elke netwerkafstand naar het IP-adres van een doelapparaat, mits dit gebeurt tijdens de PXE-bootsequentie. Een aanvaller kan een denial-of-service veroorzaken door de opstartsequentie te laten vastlopen. Wanneer de aanvaller weet welke firmwarebuild het doelwit gebruikt, kan hij een "vervalst event" plaatsen dat de kwaadaardige code uitvoert op de CPU in de UEFI-firmwareomgeving. De code draait in ring 0, het meest bevoorrechte uitvoeringsniveau van een CPU. Omdat exploits attesteringsprocessen omzeilen — die bedoeld zijn om cryptografisch aan remote servers te bewijzen dat de hardware veilig is — bieden ze een cruciale kans om beperkte privileges te verhogen.
Een reeks van UEFI-kwetsbaarheden
CVE-2026-97631 voegt zich bij een lange lijst van eerder ontdekte kwetsbaarheden in UEFI of code die nauw daarmee samenwerkt. De ernstigste daarvan, LogoFail, kwam voort uit logo-afbeeldingen die waren opgenomen in de UEFI van vrijwel elke hardwarefabrikant. Renderingsfouten stelden aanvallers in staat om de keten van vertrouwen die UEFI afdwingt te ondermijnen en kwaadaardige componenten te installeren voordat het besturingssysteem werd geladen of Secure Boot werd uitgevoerd. PixieFail was een kwetsbaarheid die vergelijkbaar was met CVE-2026-97631; ook deze was het resultaat van foutieve PXE-bootfouten in EDK2. Na de ontdekking van die kwetsbaarheid startten onderzoekers meerdere fuzzing-projecten om andere kritieke fouten in de open-source codebibliotheek aan het licht te brengen. Het lijkt erop dat deze inspanningen deze laatste fout niet hebben gevonden.
Andere onlangs ontdekte UEFI-fouten zijn:
- PKFail: een falen in de toeleveringsketen als gevolg van testplatform-sleutels (niet voor productie), die meer dan een decennium publiekelijk beschikbaar waren voordat ze werden ontdekt en werden gebruikt in honderden apparaatmodellen.
- BootHole
- Bootkit
- BlackLotus
Net als bij CVE-2026-97631 is het exploiteren van deze payloads aantrekkelijk omdat het aanvallers in staat stelt machines aan het begin van het opstartproces te infecteren, voordat TPM en andere beveiligingen worden geladen, waardoor ze maximale schade kunnen aanrichten. Gezien de wijdverspreidheid van CVE-2026-97631, zegt Moore dat het waarschijnlijk een "forever" bug is die zal blijven voortbestaan in systemen waarvoor geen ondersteuning meer wordt geboden.
Beperkingen en risico's
Er zijn belangrijke kanttekeningen en beperkingen bij het exploiteren van deze nieuwste kwetsbaarheid. Zoals vermeld is een zeker niveau van controle over een lokaal netwerk een vereiste. Dit beperkt exploitatie waarschijnlijk tot insiders of aanvallers (zoals natiestaten of ransomware-operators) die erin slagen om laagwaardige toegang tot een netwerk te krijgen en op zoek zijn naar een manier om systeemrechten te verhogen. Er is tot nu toe geen bewijs dat CVE-2026-97631 een initieel toegangspunt tot een netwerk biedt.
Er zijn ook andere hindernissen. Jesse Michael, principal researcher bij firmwarebeveiligingsbedrijf Eclypsium, vertelde Ars: "Om de kwetsbaarheid zelf te exploiteren, moet een aanvaller specifieke adressen binnen het doelsysteem raden. Het is dus niet iets waarbij je één enkele exploit naar elk doel kunt sturen en RCE (Remote Code Execution) krijgt over een divers scala aan apparaten; het moet worden afgestemd op elk doelmodel/versie/configuratie, aangezien de adressen veranderen op basis daarvan."
Hij voegt eraan toe: "In tegenstelling tot sommige van de eerdere, high-profile kwetsbaarheden zoals BootHole, Black Lotus en Baton Drop, kan deze kwetsbaarheid worden opgelost met een eenvoudige codefix. Dit vereist het implementeren van een BIOS/UEFI-update, maar men hoeft niet te dealen met intrekkingen, updates van pk/kek/db/dbx-sleutelbeheer, of het bijwerken van het besturingssysteem en voorzieningsmedia, zoals je moet doen bij Secure Boot-omzeilingen in de bootloader zelf."
Wie is getroffen?
CVE-2026-97631 treft geen thuisgebruikers, gebruikers van kleine kantoren, of andere gebruikers die hun apparaten uitsluitend vanaf schijfstations opstarten. In plaats daarvan is het alleen van toepassing op organisaties met machines die opstarten vanaf lokale netwerken, of mogelijk vanaf resources die verbonden zijn met het internet. Zelfs dan moet de doel firmware vertrouwen op EDK2 (in tegenstelling tot een andere referentie-implementatie) en de PXE-functionaliteit gebruiken (die standaard is ingeschakeld).
In een e-mail stelde Intel dat geen van zijn "commerciële producten die momenteel onder beveiligingsondersteuning vallen" naar bekend worden getroffen. "Intel neemt de getroffen EDK2-functionaliteit niet op in zijn referentiecode, hoewel het kan worden geïntegreerd door een OEM-bordleverancier of systeemfabrikant," voegde het bedrijf toe. Het adviseerde klanten om contact op te nemen met hun systeemfabrikant voor specifiek advies. Publiekelijk beschikbare Intel-referentiecode verwijst echter wel naar EDK2. Bovendien heeft TianoCore aangegeven dat elke door Intel geleverde UEFI-ontwikkelingskit "een volledig gevalideerde implementatie is... voor een specifieke revisie van de EDK II-broncode." Veel andere Intel-documenten verwijzen eveneens naar EDK2.
Arm reageerde ondertussen op een lijst met vragen: "CVE-2026-97631 is niet direct van toepassing op de productportfolio van Arm." Net als Intel leent de firmware die het bedrijf beschikbaar stelt echter zwaar van EDK2. TianoCore heeft de afhankelijkheid van Arm van EDK2 eveneens gedocumenteerd.
Hoewel het mogelijk is dat sommige platforms vrij zijn van EDK2-code, is het raadzaam voor gebruikers van alle servers om te onderzoeken of CVE-2026-97631 hen treft. Vragen gestuurd naar AMD, Phoenix Technologies, AMI, Microsoft en Amazon bleven onbeantwoord op het moment van publicatie. Zonder concrete antwoorden over het gebruik van EDK2 door deze organisaties is het onmogelijk om te zeggen welke apparaten precies zijn getroffen en welke acties zij of hun gebruikers moeten ondernemen. Vertegenwoordigers van het TianoCore Project reageerden eveneens niet.
Advies voor getroffen partijen
Gebruikers die mogelijk zijn getroffen, wordt aangeraden het volgende te doen:
- Contact opnemen met de fabrikant van de firmware die wordt gebruikt om systemen op te starten en om begeleiding vragen.
- Netwerk-bootmogelijkheden uitschakelen, indien mogelijk, ten minste tijdelijk.
- Beveiligingsfuncties zoals TPM en Secure Boot altijd inschakelen in firmwareconfiguraties waar mogelijk, hoewel deze specifieke verdedigingen niet beschermen tegen deze specifieke dreiging.
- Logs monitoren op tekenen van exploitatiepogingen.
Code-uitvoeringsfout in UEFI-firmware treft de meeste servers op aarde
Beveiligingsexperts wereldwijd worden geconfronteerd met de taak om te reageren op een nieuwe, onhandig onthulde kwetsbaarheid voor code-uitvoering. Deze keer gaat het om boot-time firmware die wordt gebruikt door de meeste serverleveranciers en datacenters ter wereld.
De kwetsbaarheid, met een ernstscore van 9,5 uit 10, bevindt zich in TianoCore EDK II, een open-source codebase die hardwarefabrikanten en cloudproviders gebruiken om de UEFI-firmware te maken die draait tijdens de opstartsequentie. Vorig jaar noemde een vertegenwoordiger van het UEFI Forum EDK2 de "vooraanstaande oplossing/implementatie van de UEFI-specificaties." Vrijwel alle UEFI-leveranciers (soms nog IBV's of independent BIOS vendors genoemd), waaronder AMI, Insyde en Phoenix, maken uitgebreid gebruik van deze referentiecode. Ook Project Mu, de verharde EDK2-fork van Microsoft, maakte gebruik van de code die het kwetsbare component bevat.
De kwetsbaarheid, geregistreerd als CVE-2026-97631, is een fout in het geheugenbeheer van een ICMP-component. Aanvallers kunnen dit exploiteren om kwaadaardige code uit te voeren voordat het besturingssysteem en de firmware beveiligingen zoals Secure Boot kunnen implementeren. Secure Boot stelt normaal gesproken een 'keten van vertrouwen' (chain of trust) vast voor alle code die tijdens het opstarten wordt geladen, inclusief de Trusted Platform Module (TPM). Hoewel de uiteindelijke payloads die via CVE-2026-97631 worden afgeleverd geen persistentie hebben — wat betekent dat ze slechts één keer worden uitgevoerd — kunnen ze aanvallers een grote opening bieden om andere payloads te installeren die telkens opnieuw in een vroeg stadium van het opstartproces draaien.
Een voortijdige onthulling
De partijen die CVE-2026-97631 ontdekten — Alex Matrosov van Anthropic en Dan Holmes van Google — hadden afgesproken de kwetsbaarheid geheim te houden tot een gecoördineerde openbaarmaking die gepland stond voor januari. AMI, een fabrikant van moederborden en andere hardware, publiceerde echter vorige maand een pull request waarin de kwetsbaarheid werd gedetailleerd en een codefix was opgenomen. Zodra deze post ter kennis kwam van de ontdekkers, publiceerden leden van het TianoCore-project vorige week een openbaar advies.
Nu de patchcode publiekelijk beschikbaar is, zal het voor geavanceerde hackers triviaal zijn om te leren hoe de kwetsbaarheid wordt geactiveerd en om werkende exploits te bouwen. De urgentie wordt verder vergroot door het feit dat het patchen van UEFI-codekwetsbaarheden in miljoenen apparaten, verkocht en gebruikt door duizenden hardwarefabrikanten en cloudproviders, omslachtig en tijdrovend is. De melding van deze kwetsbaarheid komt zes dagen na een andere mislukte onthulling, waarbij het ging om een kritieke code-uitvoeringskwetsbaarheid in de programmeertaal PHP.
HD Moore, maker van Metasploit en chief research officer bij beveiligingsbedrijf Dragos, verklaart: "Deze kwetsbaarheid in de ICMP-parser van de EDK2-netwerkstack is interessant vanwege de manier waarop het de keten van vertrouwen en het bredere ecosysteem beïnvloedt. Een aanvaller die een nabijgelegen endpoint of server wil compromitteren, zou deze bug kunnen gebruiken om de programmaflow te kapen op een punt waar het opstartproces nog toegang heeft tot gevoelige componenten, zoals de TPM van het endpoint. Dit zou kunnen worden gebruikt om schijfversleuteling te doorbreken in gevallen waarin een aanvaller kortstondig netwerktoegang heeft (en het zou nog gemakkelijker zijn in een scenario van diefstal)."
Technische werking
CVE-2026-97631 is een 16 jaar oude buffer overflow in de PXE-Base Code driver (NetworkPkg/UefiPxeBcDxe). Deze driver is verantwoordelijk voor het mogelijk maken van het opstarten van servers, opslagapparatuur en andere apparaten met code die is gedownload van een lokaal netwerk. Tijdens dit proces — bekend als de pre-execution environment boot — gebruikt de driver een netwerklistener om te monitoren op ICMP-fouten. Omdat de driver geen limiet van 504 bytes afdwingt voor het kopiëren van het geheugen, kunnen aangrenzende gegevens worden overschreven. Een kwaadaardige insider of een hacker die toegang heeft gekregen tot een lokaal netwerk, kan een foutmelding sturen die code toevoegt voorbij deze limiet. De IUEFI-module die op de CPU draait, raakt hierdoor corrupt.
Het officiële advies stelt het als volgt:
Tijdens netwerkboot houdt de PXE Base Code driver (NetworkPkg/UefiPxeBcDxe) een ontvangstverzoek open voor ICMP-foutmeldingen en kopieert elke ontvangen melding naar het vaste veld van 504 bytes Mode.IcmpError van zijn private contextstructuur. De afhandeling van de grenzen van de kopieerlus is onjuist in zowel de IPv4- als de IPv6-handlers (PxeBcIcmpErrorDpcHandle en PxeBcIcmp6ErrorDpcHandle): voor een bericht langer dan 504 bytes worden er nog steeds bytes naar het veld gekopieerd, en de bestemmingspointer wordt gevorderd met de cumulatieve lengte in plaats van de lengte per fragment, waardoor een te groot bericht bytes die door de aanvaller worden beheerd, voorbij het veld schrijft. Niets eerder in het ontvangstpad beperkt de berichtlengte.
De kwaadaardige fout kan worden verzonden via een eenvoudige unicast vanaf elke netwerkafstand naar het IP-adres van een doelapparaat, mits dit gebeurt tijdens de PXE-bootsequentie. Een aanvaller kan een denial-of-service veroorzaken door de opstartsequentie te laten vastlopen. Wanneer de aanvaller weet welke firmwarebuild het doelwit gebruikt, kan hij een "vervalst event" plaatsen dat de kwaadaardige code uitvoert op de CPU in de UEFI-firmwareomgeving. De code draait in ring 0, het meest bevoorrechte uitvoeringsniveau van een CPU. Omdat exploits attesteringsprocessen omzeilen — die bedoeld zijn om cryptografisch aan remote servers te bewijzen dat de hardware veilig is — bieden ze een cruciale kans om beperkte privileges te verhogen.
Een reeks van UEFI-kwetsbaarheden
CVE-2026-97631 voegt zich bij een lange lijst van eerder ontdekte kwetsbaarheden in UEFI of code die nauw daarmee samenwerkt. De ernstigste daarvan, LogoFail, kwam voort uit logo-afbeeldingen die waren opgenomen in de UEFI van vrijwel elke hardwarefabrikant. Renderingsfouten stelden aanvallers in staat om de keten van vertrouwen die UEFI afdwingt te ondermijnen en kwaadaardige componenten te installeren voordat het besturingssysteem werd geladen of Secure Boot werd uitgevoerd. PixieFail was een kwetsbaarheid die vergelijkbaar was met CVE-2026-97631; ook deze was het resultaat van foutieve PXE-bootfouten in EDK2. Na de ontdekking van die kwetsbaarheid startten onderzoekers meerdere fuzzing-projecten om andere kritieke fouten in de open-source codebibliotheek aan het licht te brengen. Het lijkt erop dat deze inspanningen deze laatste fout niet hebben gevonden.
Andere onlangs ontdekte UEFI-fouten zijn:
- PKFail: een falen in de toeleveringsketen als gevolg van testplatform-sleutels (niet voor productie), die meer dan een decennium publiekelijk beschikbaar waren voordat ze werden ontdekt en werden gebruikt in honderden apparaatmodellen.
- BootHole
- Bootkit
- BlackLotus
Net als bij CVE-2026-97631 is het exploiteren van deze payloads aantrekkelijk omdat het aanvallers in staat stelt machines aan het begin van het opstartproces te infecteren, voordat TPM en andere beveiligingen worden geladen, waardoor ze maximale schade kunnen aanrichten. Gezien de wijdverspreidheid van CVE-2026-97631, zegt Moore dat het waarschijnlijk een "forever" bug is die zal blijven voortbestaan in systemen waarvoor geen ondersteuning meer wordt geboden.
Beperkingen en risico's
Er zijn belangrijke kanttekeningen en beperkingen bij het exploiteren van deze nieuwste kwetsbaarheid. Zoals vermeld is een zeker niveau van controle over een lokaal netwerk een vereiste. Dit beperkt exploitatie waarschijnlijk tot insiders of aanvallers (zoals natiestaten of ransomware-operators) die erin slagen om laagwaardige toegang tot een netwerk te krijgen en op zoek zijn naar een manier om systeemrechten te verhogen. Er is tot nu toe geen bewijs dat CVE-2026-97631 een initieel toegangspunt tot een netwerk biedt.
Er zijn ook andere hindernissen. Jesse Michael, principal researcher bij firmwarebeveiligingsbedrijf Eclypsium, vertelde Ars: "Om de kwetsbaarheid zelf te exploiteren, moet een aanvaller specifieke adressen binnen het doelsysteem raden. Het is dus niet iets waarbij je één enkele exploit naar elk doel kunt sturen en RCE (Remote Code Execution) krijgt over een divers scala aan apparaten; het moet worden afgestemd op elk doelmodel/versie/configuratie, aangezien de adressen veranderen op basis daarvan."
Hij voegt eraan toe: "In tegenstelling tot sommige van de eerdere, high-profile kwetsbaarheden zoals BootHole, Black Lotus en Baton Drop, kan deze kwetsbaarheid worden opgelost met een eenvoudige codefix. Dit vereist het implementeren van een BIOS/UEFI-update, maar men hoeft niet te dealen met intrekkingen, updates van pk/kek/db/dbx-sleutelbeheer, of het bijwerken van het besturingssysteem en voorzieningsmedia, zoals je moet doen bij Secure Boot-omzeilingen in de bootloader zelf."
Wie is getroffen?
CVE-2026-97631 treft geen thuisgebruikers, gebruikers van kleine kantoren, of andere gebruikers die hun apparaten uitsluitend vanaf schijfstations opstarten. In plaats daarvan is het alleen van toepassing op organisaties met machines die opstarten vanaf lokale netwerken, of mogelijk vanaf resources die verbonden zijn met het internet. Zelfs dan moet de doel firmware vertrouwen op EDK2 (in tegenstelling tot een andere referentie-implementatie) en de PXE-functionaliteit gebruiken (die standaard is ingeschakeld).
In een e-mail stelde Intel dat geen van zijn "commerciële producten die momenteel onder beveiligingsondersteuning vallen" naar bekend worden getroffen. "Intel neemt de getroffen EDK2-functionaliteit niet op in zijn referentiecode, hoewel het kan worden geïntegreerd door een OEM-bordleverancier of systeemfabrikant," voegde het bedrijf toe. Het adviseerde klanten om contact op te nemen met hun systeemfabrikant voor specifiek advies. Publiekelijk beschikbare Intel-referentiecode verwijst echter wel naar EDK2. Bovendien heeft TianoCore aangegeven dat elke door Intel geleverde UEFI-ontwikkelingskit "een volledig gevalideerde implementatie is... voor een specifieke revisie van de EDK II-broncode." Veel andere Intel-documenten verwijzen eveneens naar EDK2.
Arm reageerde ondertussen op een lijst met vragen: "CVE-2026-97631 is niet direct van toepassing op de productportfolio van Arm." Net als Intel leent de firmware die het bedrijf beschikbaar stelt echter zwaar van EDK2. TianoCore heeft de afhankelijkheid van Arm van EDK2 eveneens gedocumenteerd.
Hoewel het mogelijk is dat sommige platforms vrij zijn van EDK2-code, is het raadzaam voor gebruikers van alle servers om te onderzoeken of CVE-2026-97631 hen treft. Vragen gestuurd naar AMD, Phoenix Technologies, AMI, Microsoft en Amazon bleven onbeantwoord op het moment van publicatie. Zonder concrete antwoorden over het gebruik van EDK2 door deze organisaties is het onmogelijk om te zeggen welke apparaten precies zijn getroffen en welke acties zij of hun gebruikers moeten ondernemen. Vertegenwoordigers van het TianoCore Project reageerden eveneens niet.
Advies voor getroffen partijen
Gebruikers die mogelijk zijn getroffen, wordt aangeraden het volgende te doen:
- Contact opnemen met de fabrikant van de firmware die wordt gebruikt om systemen op te starten en om begeleiding vragen.
- Netwerk-bootmogelijkheden uitschakelen, indien mogelijk, ten minste tijdelijk.
- Beveiligingsfuncties zoals TPM en Secure Boot altijd inschakelen in firmwareconfiguraties waar mogelijk, hoewel deze specifieke verdedigingen niet beschermen tegen deze specifieke dreiging.
- Logs monitoren op tekenen van exploitatiepogingen.
Groetjes,