Direct naar de inhoud
Cybersecurity

PwnEscape Linux kernel: hostgeheugen uitlekken

PwnEscape Linux kernel

Een kritieke fout in de Linux kernel laat toe dat code binnen een virtuele machine (VM) het geheugen van de host kan lezen. De kwetsbaarheid kreeg de naam PwnEscape Linux kernel en is gecatalogiseerd als CVE-2026-99999. Onderzoekers demonstreerden het in een cloud-omgeving van Vercel, maar het probleem zit niet in de configuratie van één provider: het ligt in de netwerkcode van de kernel zelf.

Wat dit extra belangrijk maakt voor organisaties met gedeelde of virtueel gescheiden omgevingen: de aanval raakt het shared layer-principe dat veel clouds gebruiken om klantenworkloads van elkaar af te schermen. Gelukkig is er een duidelijke fix en kun je met de juiste controleactie snel het risico beperken.

Wat is PwnEscape Linux kernel (CVE-2026-99999)?

PwnEscape Linux kernel is een kwetsbaarheid in het Linux-netwerkpad. De kern van het probleem is dat speciaal gemaakte pakketten vanuit een gast-VM informatie kunnen teruggeven die onderdeel is van het hostgeheugen. In dezelfde fout vallen ook andere gevolgen: een host kan crashen en er kan (in een lab-setting) code op de host uitgevoerd worden.

De onderzoeker toonde drie scenario’s aan die uit één en dezelfde kernelfout voortkomen: lezen van hostgeheugen, crashen van de host en uiteindelijk code-executie. Over het uitlezen van klantdata meldt de bron expliciet dat er in de challenge-rapportages geen aanwijzingen waren voor het lezen van bestanden, geheimen of applicatiegegevens.

Wie kan erdoor geraakt worden?

Deze kwetsbaarheid is geen “open internet” aanval. Het aanvalspad vereist lokale toegang binnen de VM: een aanvaller moet al code kunnen uitvoeren in een guest-omgeving. Dat betekent in gewone woorden: een kwaadwillende partij moet eerst een foothold in de virtuele machine hebben.

In de praktijk is dat vooral relevant voor omgevingen waar aanvallers via onveilige applicaties, foutieve isolatie of andere routes uiteindelijk tóch in een VM terechtkomen. Denk bijvoorbeeld aan het scenario waarin een klantcodebasis of applicatie in een sandbox draait en die code wordt misbruikt.

De bron vermeldt verder dat er geen melding is van actief misbruik in de echte wereld en dat het niet in CISA’s catalogus van actief uitgebuite kwetsbaarheden stond.

Waarom gaat de impact verder dan één cloud?

Vercel draait klantcode per microVM (Firecracker microVMs) op bare-metal hosts in EC2. Die microVM vormt een barrière tussen klant en host én tussen klanten onderling. Maar de kwetsbaarheid zit niet in de microVM “muur”; hij zit in de Linux kernel-netwerkstack die op de host draait.

Omdat veel cloudplatforms klantworkloads scheiden via (gedeelde) Linux kernel-lagen, ontstaat er een breder effect: de dreiging gaat meer over gedeelde infrastructuurcomponenten dan over de specifieke sandboxtechniek van één leverancier.

Wat liet de onderzoeker precies zien?

De demonstratie werkte door vanuit een VM netwerkpakketten te versturen die de kernel op een fout manier laat handelen. Elk pakket kon ongeveer 32 bytes hostgeheugen meenemen naar terugkerende inhoud richting de aanvaller. Door door te blijven zenden, kon een gast doorgaans doorgaan met het opbouwen van uitleesbare informatie.

Voor het crashen en het bereiken van hostcontrole waren er in de lab-omgeving slechts speciaal vervaardigde pakketten nodig. Wel is benadrukt dat het om een testresultaat ging onder omstandigheden die overeenkwamen met de eigen setup van de onderzoeker, niet om een claim van praktische root-toegang in productieomgevingen van vendors.

Daarnaast gaf de bron context over het onderzoeksproces: de onderzoeker beschreef een eigen AI-ondersteund systeem om hypotheses en code-traces te testen en interessant gebleken bevindingen te valideren met echte kernelgedrag in hun eigen gecontroleerde systemen.

Hoe ernstig is de kwetsbaarheid?

De kernelmaintainers gaven de kwetsbaarheid een score van 9,3 van 10 en kwalificeerden die als kritiek (Critical). De National Vulnerability Database van de VS had de invoer ontvangen, maar die review was nog niet afgerond op het moment van de bronpublicatie.

Ook al is het risico direct hoog door de aard van het effect (hostgeheugen lezen, host verstoren en potentieel code-uitvoering), de exploitbaarheid hangt af van de voorwaarde: je moet code binnen de guest kunnen draaien.

De fix: één kernelwijziging die je moet meenemen

Er is een specifieke patch beschikbaar. De fix bestaat uit één Linux kernel commit (6785011f8b16) die is geschreven door Michael S. Tsirkin van Red Hat en later is gemerged in de mainline kernel.

De wijziging voegt een extra controle toe zodat checksumdata van een pakket niet kan wijzen naar een locatie vóór de IPv4-header, voordat de kernel verder gaat met het verwerken van dat pakket. De bron geeft aan dat deze check op vijf plekken in de netwerkcode wordt toegepast.

Belangrijk: de fix is bewust “defence in depth”. Dat betekent dat het een verdedigingslaag toevoegt, maar dat een volledigere check bij het binnenkomen van pakketten nog verdere ontwikkeling vraagt.

Zo pak je het praktisch aan (patchstappen)

De bron is helder over één cruciaal punt: je moet de hostkernel patchen, niet alleen de kernel in de guest-VM. Het probleem zit immers in de kernel die op het hostniveau draait.

Concreet worden twee aanpakken genoemd:

  • Update de hostkernel naar een van de eerste vaste versies uit de supported stable branches, of naar een vendor/build die de fix bevat. Reboot vervolgens in die nieuwe kernel.
  • Wacht je met patchen? Dan zijn er geen afzonderlijke “workarounds” genoemd. Je kunt wel de impact beperken door de mogelijkheden van een succesvolle aanval te verkleinen.

De bron raadt bovendien aan om niet alleen naar een version-number te kijken. Distributies leveren vaak custom kernelbuilds en verwerken fixes zonder dat het version label verandert. Controleer daarom de advisory van je distributie en bevestig dat de fix daadwerkelijk in de hostkernel zit die draait.

Welke mitigaties helpt het om te doen?

Hoewel mitigaties geen vervanging zijn voor patchen, beschrijft Vercel maatregelen die het praktische bereik van misbruik beperken. Voorbeelden die genoemd worden:

  • Hostkernen up-to-date houden.
  • Nesten van virtualisatie uitschakelen (nested virtualization).
  • Elke microVM draaien onder een jailer die alleen de benodigde rechten geeft aan het microVM-proces.

Dit verkleint het “wat kan de aanvaller daarna nog doen”-deel. De bron benadrukt echter dat dit het kernelprobleem zelf niet wegneemt.

De context: gevonden in een challenge

De kwetsbaarheid kwam naar voren via een twee weken durende challenge van Vercel in augustus, met een totale beloning tot $1 miljoen voor het succesvol doorbreken van de sandbox. Geen enkele inzending haalde dat volledige bedrag. De topuitkering per rapport lag op $50.000.

Vercel betaalde in totaal $242.000 uit over 1.285 rapporten, waarbij PwnEscape de enige Critical bevinding uit die reeks was. De onderzoeker rapporteerde dat het vinden van de fout enkele dagen duurde met AI-ondersteunde analyse en menselijke validatie.

Waarom dit ook buiten de cloud aandacht verdient

Zelfs als je niet “cloud native” werkt, raakt deze klasse issues je als je virtualization/containers gebruikt op hosts waar dezelfde kernelcomponenten draaien. Het is daarom verstandig om je als security- en platformteam te focussen op drie vragen: draait op je hosts de Linux kernel met de juiste fix?, patch je hosts tijdig (dus niet alleen de guests), en kun je de impact beperken als een aanvaller toch een foothold in een VM krijgt?

Door de stappen uit de bron te volgen—hostkernel updaten, advisory’s checken en je mitigaties aanscherpen—maak je van deze ernstige kwetsbaarheid weer een beheersbaar risico.

Conclusie

PwnEscape Linux kernel (CVE-2026-99999) is een kritieke kwetsbaarheid in de Linux kernel-netwerkcode die een aanvaller binnen een VM kan helpen hostgeheugen uit te lezen. Hoewel exploitatie lokale guest-toegang vereist en er (volgens de bron) geen echte aanvallen zijn gemeld, is de impact op gedeelde infrastructuur groot genoeg om nú actie te nemen.

Patch daarom de hostkernel naar de fix (commit 6785011f8b16 of een vendorbuild met dezelfde wijziging), valideer via distributie-advisories dat het echt in jouw hostkernels zit en neem waar nodig aanvullende beperkingsmaatregelen mee als tijdelijke overbrugging.

Voor bredere context over hoe cloud- en sandboxkwesties zich vertalen naar concrete security-acties, kun je ook lezen hoe organisaties hun aanpak kunnen verbeteren richting “van melding naar actie”: contextuele cyberdefensie van losse meldingen naar actie.

Bron: https://thehackernews.com/2026/10/critical-pwnescape-linux-kernel.html