Een UEFI PXE-kwetsbaarheid met de naam CVE-2026-97631 kan ervoor zorgen dat een aanvaller tijdens een netwerkboot al code kan uitvoeren vóór Secure Boot en andere opstartbeveiligingen. Dat maakt het risico niet alleen technisch, maar vooral qua timing: de omgeving is dan nog niet “veilig” gecontroleerd door de gebruikelijke checks van het opstartproces.
De fout zit in EDK II, open-source firmwarecode die veel hardwarefabrikanten gebruiken om hun UEFI-firmware te bouwen. De kwetsbaarheid is vooral relevant voor omgevingen waarin systemen booten via PXE (Preboot eXecution Environment), bijvoorbeeld servers en apparatuur in datacenters.
Wat is de kern van de UEFI PXE-kwetsbaarheid?
De bug is een buffer overflow in de PXE-onderdelen van EDK II. Bij PXE boot haalt een machine een opstartimage niet van lokale schijf, maar via het netwerk.
Tijdens die netwerkboot luistert de PXE-code naar netwerkberichten—zoals ICMP foutmeldingen en statusberichten van netwerkapparatuur. Vervolgens kopieert de firmware die berichten naar een vast geheugengebied van 504 bytes. De beveiligingschecks bij die kopie zijn fout: berichten die groter zijn dan de bedoelde ruimte kunnen over de grens heen schrijven en nabijgelegen geheugen overschrijven met door de aanvaller gekozen data.
Waarom is uitvoering vóór Secure Boot extra gevaarlijk?
Het ernstige effect zit in het moment waarop de kwaadaardige code kan starten. Wanneer de exploit werkt, draait de code in de firmware, dus voordat Secure Boot en andere beveiligingen van het opstarttraject hun controles hebben uitgevoerd.
Met een simpele poging resulteert het vaak in een crash: de boot loopt vast en het systeem start niet. Het daadwerkelijk plaatsen van werkende code is lastiger en vereist kennis van de specifieke firmware build. De begeleidende advisory beschrijft dat een aanvaller, als de precieze firmware bekend is, een constructie kan “planten” die de firmware ertoe aanzet om de eigen code te laten draaien.
Belangrijk detail: de code die zo draait, blijft niet automatisch doorlopen na een reboot. Wel kan die éénmalige uitvoering worden misbruikt om aanvullende componenten neer te zetten die wél bij volgende boot worden geladen.
Voor wie speelt dit risico?
De kwetsbaarheid zit in EDK II tot en met edk2-stable202608 (de nieuwste stable versie uit de genoemde periode, gedateerd 21 augustus). EDK II fungeert als referentiecode voor vrijwel alle UEFI-fabrikanten, waardoor het potentieel breed door kan werken in firmware die bovenop EDK II is gebouwd.
PXE-netwerkboot staat in de standard build van EDK II standaard aan. Dat betekent dat organisaties die hun apparaten over het netwerk laten opstarten, primair geraakt worden. Thuis- of kantoorgebruikers die uitsluitend vanaf lokale schijf booten, vallen in de praktijk minder vaak onder dit scenario.
De status van exacte getroffen producten is niet volledig bekend. Wel zijn er aanwijzingen uit distributies: Red Hat vermeldt dat het edk2-pakket in Red Hat Enterprise Linux 8, 9 en 10 getroffen is en nog niet is gefixt. Ook SUSE en Debian markeren vergelijkbare edk2-pakketten in diezelfde richting (nog niet opgelost, op dat moment).
Is er een patch of workaround?
Ja, er is een codefix samengevoegd in de EDK II-bron. Die wijziging herwerkt de foutieve kopieerlus zodat een oversize bericht wordt
De fix is toegevoegd aan de main development-branch rond 15 oktober. Maar: de stable releases bevatten de fix nog niet. Daardoor hebben veel gebruikers op dat moment nog geen “kant-en-klare” update om direct uit te rollen.
Er is ook genoemd dat Project Mu (de geharde UEFI-fork van Microsoft) de fix al heeft doorgevoerd naar releasebranches en tagged builds heeft gemaakt rond 26 oktober. Dat betekent echter niet automatisch dat elk apparaat onmiddellijk een firmware-update krijgt—dat hangt af van de firmwareleverancier en de OEM die de update levert.
Omdat er geen generieke workaround is die de bug volledig omzeilt, is het belangrijkste praktische middel op operationeel niveau: PXE uitschakelen waar dat niet nodig is. Dat vermindert de kans dat de kwetsbare code überhaupt in de netwerkboot-route terechtkomt.
Wat je nu kunt doen als beheerder
Ondanks dat de technische fix al beschikbaar is in de broncode, ligt de bottleneck bij het implementeren via firmware-updates. Daarom draait de eerste fase om risicobeperking en detectie.
- Inventariseer PXE-gebruik: welke systemen booten via netwerk (PXE), en op welke netwerksegmenten?
- Schakel PXE uit waar mogelijk: als lokale schijf of andere bootopties volstaan, is dit de meest directe reductie van blootstelling.
- Volg firmware- en OEM-updates: kijk wanneer leveranciers UEFI/BIOS-updates uitbrengen die zijn gebaseerd op de gefixt EDK II-versie.
- Let op boot-time netwerkverkeer: de advisory raadt aan om verkeer en logregels rond het opstartmoment te monitoren op pogingen of anomalieën.
- Herken “adjacent network”-aanvallen: de bug is volgens de beoordelingen niet bedoeld voor massale aanvallen vanaf het open internet, maar eerder vanuit een positie “naast” het target binnen het netwerk.
Heb je te maken met supply-chain of firmware-gevoeligheid in het algemeen? Dan is het nuttig om ook breder te kijken naar beveiliging in de keten. In dat kader kan dit artikel helpen: RCE-risico’s: patch snel. Niet omdat het dezelfde fout is, maar omdat het dezelfde beheerpremisse benadrukt: snelheid en structurele patchdiscipline.
Hoe werd de kwetsbaarheid bekend?
De advisory benoemt onderzoekers Alex Matrosov en Dan Holmes-Mitra als vinders. Zij worden in verband gebracht met een geplande disclosure die later zou plaatsvinden. Die planning werd echter versneld doordat een pull request rond 28 september publiek beschreef wat er mis was, inclusief de CVE-code en de fix.
Daarna publiceerde TianoCore (de organisatie achter EDK II) op 22 oktober de advisory. Als de patch publiek is, kunnen bekwame aanvallers de details bestuderen en hun exploit beter afstemmen op de trigger-omstandigheden.
Vooralsnog is er volgens de berichtgeving geen zicht op actief misbruik gerapporteerd, en stond het niet vermeld in de relevante “known exploited”-lijst van CISA op een bepaald moment. Dat is geen garantie voor de toekomst, maar wel een aanwijzing dat het niet al op grote schaal wordt toegepast.
Relatie met eerdere UEFI/PXE-issues
Dit is niet de eerste kwetsbaarheid in de PXE/netwerkbootlogica van EDK II. In januari 2024 werden onderzoekers gemeld met PixieFail: een set van negen flaws in hetzelfde domein, ook bereikbaar tijdens PXE-boot.
Toen fuzzingprojecten na PixieFail aan de slag gingen, vonden ze niet direct deze specifieke kwetsbaarheid. Dat onderstreept hoe complex en hardnekkig kwetsbare codepaden kunnen blijven, ook nadat er eerdere bevindingen zijn gedaan.
Conclusie
De UEFI PXE-kwetsbaarheid (CVE-2026-97631) laat zien hoe groot het effect kan zijn van bugs in firmwarecomponenten: tijdens netwerkboot kan code worden uitgevoerd vóór Secure Boot. De praktische uitdaging is dat de fix wel beschikbaar is in broncode, maar dat veel organisaties nog afhankelijk zijn van firmware-updates van hun leveranciers.
Pak het risico daarom pragmatisch aan: beperk PXE waar het niet nodig is, inventariseer getroffen systemen, monitor boot-time netwerkverkeer en wacht—met prioriteit—op toepasbare UEFI/BIOS updates.
Bron: https://thehackernews.com/2026/10/critical-16-year-old-uefi-flaw-can-run.html
