De bug is oud, het probleem is nieuw

Er is iets merkwaardigs aan CVE-2026-97631. Het lek is zestien jaar oud, zit in een stukje code dat vrijwel elke serverfabrikant en cloudprovider gebruikt, en werd pas ontdekt door twee onderzoekers die er vervolgens een half jaar over moesten zwijgen. Toen een moederbordfabrikant per ongeluk een pull request met de fix publiceerde, ging het licht uit. Binnen een week lag de volledige details op straat.

Dat is geen incident. Dat is een patroon. En het patroon vertelt iets belangrijks over de manier waarop we naar firmware kijken: als iets wat we nauwelijks controleren, nauwelijks updaten en nauwelijks begrijpen.

Waarom dit lek zo interessant is

De kwetsbaarheid zelf is technisch bijna saai: een bufferoverflow in de ICMP-parser van de PXE-bootdriver. Een klassieke fout, eentje die je in een undergraduate-cursus leert vermijden. Maar de context maakt het grimmig. Deze code draait voordat het besturingssysteem bestaat. Voordat Secure Boot zijn keten van vertrouwen heeft opgebouwd. Voordat de TPM iets kan attesteren. Een aanvaller die hier binnenkomt, staat in ring 0 van de CPU, op het meest geprivilegieerde niveau dat er is, en wel op een moment dat alle latere verdedigingslinies nog moeten beginnen.

Dat is de kern: dit is geen lek in een applicatie die je even patcht. Dit is een lek in de fundering. En de fundering wordt door miljoenen apparaten gedeeld.

De keten van vertrouwen is een keten van aannames

Wat mij het meest stoort aan de hele affaire is niet de bug, maar de reactie erop. Intel zegt dat zijn commerciële producten niet geraakt zijn, maar verwijst tegelijk naar referentiecode die wél op EDK2 leunt. Arm zegt iets soortgelijks. Ondertussen gebruikt vrijwel elke independent BIOS vendor — AMI, Insyde, Phoenix — dezelfde open source-basis. En Microsofts gehardende fork, Project Mu, bevatte de kwetsbare component ook.

Dat betekent dat de verantwoordelijkheid voor een patch verspreid is over duizenden hardwaremakers, honderden firmwareversies en talloze configuraties. In de praktijk betekent dat: geen enkele partij heeft het volledige overzicht. Iedereen wijst naar de volgende in de keten. En de eindgebruiker — de beheerder van een datacenter, de systeemintegrator — moet maar hopen dat zijn leverancier snel genoeg is.

De ironie is pijnlijk. We hebben Secure Boot gebouwd om te kunnen vertrouwen op wat er tijdens het opstarten gebeurt. Maar de code die Secure Boot mogelijk maakt, is zelf niet altijd even betrouwbaar. De keten van vertrouwen begint bij een schakel die we collectief te weinig auditen.

De keerzijde van open source

Er is een verleidelijke conclusie: dit is de prijs van open source. EDK2 is open, dus iedereen kan de bug vinden. Maar dat is te makkelijk. Het tegenargument is even sterk: omdat EDK2 open is, kon de fix tenminste snel worden gepubliceerd en gecontroleerd. Bij gesloten firmware hadden we moeten vertrouwen op de goodwil van een leverancier die misschien nooit iets had laten weten.

Toch legt dit incident een zwakke plek bloot in de manier waarop we open source-firmware onderhouden. Er zijn fuzzing-projecten gestart na eerdere lekken zoals PixieFail. Die hebben deze bug niet gevonden. Zestien jaar lang heeft niemand de ICMP-parser van de PXE-driver grondig genoeg bekeken. Dat is geen kwestie van kwaadwil, maar van capaciteit: er zijn simpelweg te weinig mensen die naar firmware kijken, en degenen die het doen, worden niet altijd betaald door de partijen die het meeste belang hebben bij een veilige bootketen.

Wat dit betekent voor de praktijk

De beperkingen van dit lek zijn reëel. Een aanvaller moet controle hebben over een lokaal netwerk, moet weten welke firmwareversie draait, en moet de exploit per model en configuratie afstemmen. Dat maakt het geen aanval voor de massa, maar wel een aantrekkelijk opstapje voor wie al binnen is: een insider, een ransomware-groep, een natiestaat. En zoals bij meer firmwarelekken het geval is, zal dit op veel end-of-support-systemen voor altijd blijven rondwaren.

De echte les is daarom niet dat we bang moeten zijn voor deze ene bug. De les is dat we onze firmware-hygiëne serieus moeten nemen op een manier die verder gaat dan een jaarlijkse BIOS-update. Dat betekent: PXE-boot uitzetten waar het niet nodig is, firmwareversies bijhouden als onderdeel van je assetmanagement, en leveranciers vragen naar hun afhankelijkheid van EDK2. En het betekent dat we als sector moeten nadenken over hoe we de mensen financieren die dit soort code wél grondig doorlichten — voordat de volgende zestien jaar oude bug opduikt.

https://arstechnica.com/security/2026/10/code-execution-flaw-in-uefi-firmware-threatens-most-servers-on-planet-earth/