Er is een nieuwe, kritieke kwetsbaarheid in de Linux-kernel bekendgemaakt die de scheiding tussen een gast-VM en het hostsysteem kan doorbreken. De fout heet Linux PwnEscape (CVE-2026-99999) en is besproken in de context van cloud-sandboxes, waaronder die van Vercel. In het onderzoek kon code binnen een virtuele machine direct hostgeheugen uitlezen, naast het laten crashen en in sommige scenario’s zelfs het uitvoeren van code op de host.
Wat belangrijk is: dit is geen aanval die zomaar van buitenaf via internet werkt. Je moet al code kunnen draaien binnen de VM (een “local” aanvalssituatie). Toch blijft het risico in gedeelde omgevingen aanzienlijk, omdat de kwetsbaarheid zit in de kernellaag die voor veel clouds en hosts dezelfde rol vervult.
Wat is Linux PwnEscape?
Linux PwnEscape is de bijnaam voor CVE-2026-99999, een fout in het netwerkcode-gedeelte van de Linux-kernel. Volgens de publieke informatie is de kwetsbaarheid niet gebonden aan een specifieke cloudconfiguratie of virtualisatieomgeving. Daardoor kan het effect zich uitbreiden naar de gedeelde laag waarop veel cloudproviders hun klanten isoleren.
Een onderzoeker van pwn.ai demonstreerde hoe speciaal vervaardigde netwerkpakketten vanuit een gast-VM problemen konden veroorzaken aan de hostkant. Daarbij gaat het om drie categorieën impact die uit dezelfde kernelbug voortkomen:
- het lezen van hostgeheugen (memory disclosure),
- het crashen van de host,
- het uitvoeren van code op de host (waargenomen in de setups van de onderzoeker).
Vercel gaf aan dat de memory leak in zijn productie-sandboxomgeving is aangetoond, maar dat er geen signalen zijn dat de fout in echte aanvallen is gebruikt.
Wat liet de onderzoeker precies zien?
De kern van de demonstratie draait om netwerkverkeer vanuit de VM. Elke pakketsituatie kon ongeveer 32 bytes aan hostgeheugen “meelekken” terug naar de gast, zolang er pakketten werden verstuurd. Daarmee wordt het potentieel bruikbaar voor aanvallers die eerst toegang tot de VM hebben.
Daarnaast bleek dat met twee speciaal gemaakte pakketten een host kan worden gecrasht en dat dit vervolgens alle sandboxen die op die host draaiden kon beïnvloeden. Ook is beschreven dat de onderzoeker in een laboratoriumopstelling tot beheerderscontrole op de host kon komen, waarmee de VM-breakout relevant wordt.
Het is daarbij wel van belang om de context scherp te houden: de onderzoeker positioneert de resultaten als laboratoriumresultaten op systemen die overeenkwamen met de challenge-opzet, en niet als een claim dat dit bij een specifieke vendor in productie is gebeurd.
Waarom raakt dit meer dan één cloud?
Veel partijen isoleren workloads op dezelfde “gedeelde” kernellaag. Bij Vercel draait sandboxing bijvoorbeeld met microVM’s op basis van Firecracker, op bare-metal hosts. Elke microVM heeft een eigen Linux-kernelcopy, waardoor klantcode geïsoleerd blijft van andere microVM’s.
Maar de bug zit in de Linux-kernel networking die de host draait. Met andere woorden: zelfs als de microVM netjes is geïsoleerd door de virtualisatielaag, kan de hostkernel een zwakke plek hebben in de verwerking van netwerkdata.
Daarbij geeft Vercel aan dat de sandbox verder was “hardened” dan standaard, en dat er geen misconfiguraties naar voren kwamen die de kwetsbaarheid zouden verklaren. Toch blijft de boodschap staan: als de hostkernel dezelfde kwetsbare code bevat, kan de isolatie minder betekenen dan verwacht.
Hoe ernstig is Linux PwnEscape?
De fout is als Critical beoordeeld met een score van 9,3 in de kwetsbaarheidsregistratie. De aanvalsvector wordt als local omschreven: je hebt dus toegang nodig om code in de VM uit te voeren voordat je de bug kunt triggeren.
Er staat bovendien in de beschrijving dat de kwetsbaarheid niet in de catalogus van actief misbruikte kwetsbaarheden voorkomt en dat er geen gerapporteerd echt misbruik is gezien. Dat neemt niet weg dat “local” in cloudland vaak praktisch betekent: als een aanvaller eenmaal in een workload komt, wordt de sprong naar de hostlaag ineens een realistische stap.
De fix: kernelpatch voor de networking-check
De oplossing bestaat uit één Linux-kernelwijziging. De wijziging is gekoppeld aan commit 6785011f8b16 en is ontwikkeld door Michael S. Tsirkin (Red Hat). Het patcht een controle op checksumdata: de kernel moet voorkomen dat checksuminformatie naar locaties kan wijzen die vóór de IPv4-header liggen, voordat de kernel netwerkverwerking doet.
In de beschrijving wordt aangegeven dat deze check op vijf plekken in de networkingcode wordt toegepast. De auteur noemt het een “defence in depth”-maatregel, en geeft tegelijk aan dat een volledigere check bij de binnenkomst van pakketten nog verder werk vereist.
Ook zijn er backports gedaan naar de stable kernelbranches. Let op: omdat distributies kernels kunnen verpakken met patches zonder de versienummer-identiteit te wijzigen, is het niet genoeg om alleen naar uname-output te kijken. Je moet de distributieadviesinformatie volgen en controleren of de hostkernel daadwerkelijk de fix bevat.
Wat moet je nu doen?
De meest directe actie is: update de hostkernel naar een versie die de fix bevat en herstart daarna. Een veelvoorkomende valkuil is dat teams alleen de kernel in de gast (de VM of microVM) updaten. Voor Linux PwnEscape geldt juist dat de kwetsbaarheid in de hostkernel zit.
Er is volgens de broninformatie geen separaat workaround-advies voor situaties waarin patching niet meteen lukt. In zo’n tussenperiode is het gebruikelijk om de impactradius te verkleinen. Vercel noemt daarbij maatregelen zoals:
- hostkernels actueel houden,
- nested virtualization uitschakelen,
- microVM’s onder Firecracker’s jailer laten draaien met alleen de benodigde permissies.
Dit lost het probleem niet op, maar kan bepalen wat een aanvaller na een exploit nog kan doen.
Vergelijkbare patronen: van VM-toegang naar platformimpact
Linux PwnEscape past in een breder patroon binnen cloudbeveiliging: aanvallen worden niet alleen “in de applicatie” bestreden, maar ook in de platformlaag waar isolatieveronderstellingen leunen op kernel- en netwerkimplementaties. Juist daarom is het belangrijk om security-activiteiten te koppelen aan de juiste context en prioritering.
Als je wilt begrijpen hoe je van losse detecties naar gerichte actie komt, kan dit artikel je helpen: Bron: https://thehackernews.com/2026/10/critical-pwnescape-linux-kernel.html
