Bad Epoll (CVE-2026-46242): het root-lek in de Linux-kernel en wat het betekent voor je servers

Een net onthuld lek in de Linux-kernel, Bad Epoll (CVE-2026-46242) genaamd, laat elke gewone gebruiker op een machine opklimmen tot volledige root-rechten, en het treft Linux-servers, desktops en Android-apparaten met kernel 6.4 of nieuwer. Het werd op 3 juli 2026 gepubliceerd, nadat onderzoeker Jaeyoung Chung een werkende exploit had ingediend bij het kernelCTF-programma van Google. Er zit al een fix in de mainline-kernel, maar de meeste distributies moeten nog een backport uitbrengen, dus de praktische taak op dit moment is om je kernelversie te controleren en de beveiligingsupdate van je distributie toe te passen zodra die verschijnt.

Er is meteen één stukje goed nieuws: op het moment van schrijven staat de fout niet in de catalogus van bekende misbruikte kwetsbaarheden van CISA, en de enige werkende exploit is de proof of concept uit de wedstrijd. Dat geeft je een venster om te patchen voordat het opduikt in echte aanvalsketens.

Wat is Bad Epoll en waarom geeft het root?

Bad Epoll is een use-after-free door een race-conditie in het epoll-subsysteem van de kernel, het mechanisme dat Linux gebruikt om tegelijk grote aantallen bestanden en netwerk-sockets in de gaten te houden. Twee delen van de kernel proberen op hetzelfde moment hetzelfde interne object op te ruimen: de ene thread geeft het geheugen vrij terwijl de andere er nog in schrijft. Die overlap laat een aanvaller kernelgeheugen op gecontroleerde wijze beschadigen en de referenties van zijn eigen proces herschrijven totdat de kernel hem als root behandelt.

Wat het lek opmerkelijk maakt, is hoe smal de opening is. Het misbruikbare race-venster is ongeveer zes machine-instructies breed, een tijdsplintertje dat zo klein is dat het lastig te raken is, zelfs als je de kwetsbare code kunt lezen. Die moeilijkheid is de reden dat niemand het meer dan twee jaar opmerkte, en ook waarom een betrouwbare exploit indrukwekkend genoeg is om een kernelCTF-uitbetaling te verdienen. Toch maakt het je niet veilig: zodra iemand de exploit schrijft, houdt het zes-instructievenster op je bescherming te zijn.

Welke kernelversies zijn getroffen?

De fout werd in 2023 geïntroduceerd door een wijziging in de epoll-code en verscheen met Linux 6.4. Alles van 6.4 tot de huidige lijn zonder de fix is kwetsbaar; oudere kernels op basis van de 6.1-reeks hadden de problematische code nooit en zijn niet getroffen. De fix is mainline-commit a6dc643c6931, die in april 2026 landde, en elke distributie backport hem volgens zijn eigen schema.

Kernellijn	Getroffen?	Wat te doen
6.1 LTS en ouder	Nee	Fout is ouder dan deze; geen actie voor deze CVE
6.4 – huidig (ongepatcht)	Ja	Werk bij naar de gepatchte build van je distributie en herstart daarna
Elke build met commit a6dc643c6931	Nee	Al opgelost; bevestig dit en ga verder
Android op 6.4+-kernels	Ja	Wacht op de beveiligingsupdate van het apparaat of de leverancier

Let op: Android valt binnen bereik waar het apparaat een kernel 6.4 of nieuwer meelevert; hardware die nog op 6.1 draait, zoals sommige bestaande telefoons, is niet getroffen. Op servers volgt het risico de kernel, niet de naam van de distributie, dus een "stabiele" LTS-distributie kan nog steeds een getroffen 6.x-kernel draaien.

Hoe je je eigen servers controleert en patcht

Begin met het uitlezen van de draaiende kernelversie en vergelijk die met het advies van je distributie. Op elke Linux-machine:

uname -r        # bijv. 6.8.0-40-generic — 6.4+ betekent: controleer op de patch
apt list --upgradable 2>/dev/null | grep -i linux   # Debian/Ubuntu
dnf updateinfo list security | grep -i kernel        # Fedora/RHEL-familie

Pas daarna de beveiligingsupdate toe en herstart naar de nieuwe kernel. Een gepatcht kernelpakket doet niets totdat je er daadwerkelijk naar herstart, en dat is de stap die mensen overslaan. Als je niet meteen downtime kunt nemen, kan een live-patchingdienst (kernel livepatch op Ubuntu, kpatch op RHEL) het gat op ondersteunde kernels dichten zonder herstart, waardoor je tijd wint tot een onderhoudsvenster. Houd het beveiligingskanaal van je distributie in de gaten — Ubuntu USN's, de Debian security tracker of de adviesfeed van je leverancier — voor de vermelding van CVE-2026-46242, want de mainline-fix en de verpakte backport komen op verschillende dagen.

Waarom een "alleen lokaal" lek er toch toe doet voor één enkele VPS

Het is verleidelijk om je schouders op te halen bij een lokaal lek voor rechtenescalatie: een aanvaller moet al op de machine zitten, dus als niemand een shell heeft, valt er niets te escaleren. Die redenering houdt in de praktijk geen stand. Lokale root is de tweede fase van de meeste echte inbraken. Een webapp met een lek voor uitvoering van code op afstand, een uitgelekte deploy-sleutel, een vergiftigde dependency of een gecompromitteerde container geven een aanvaller allemaal enige code-uitvoering als gebruiker zonder rechten. Bad Epoll is wat die voet tussen de deur verandert in volledige controle over de host, inclusief elke andere app en database op dezelfde machine.

Dat is precies de vorm van het risico op een zelfbeheerde VPS, waar je app, je database en je control plane meestal één kernel delen. Als je je eigen server draait, hoort dit lek op dezelfde hardeningschecklist als SSH-sleutels en een firewall — de basis die we doornemen in onze gids voor het zelf hosten van apps op een VPS. Het is ook een herinnering dat perimeterverdediging op zichzelf niet genoeg is; gelaagde controles zoals het zero-trust-model gaan ervan uit dat een inbraak zal gebeuren en beperken wat één gecompromitteerd account kan bereiken.

Wordt Bad Epoll in het wild misbruikt?

Nog niet. Er is geen teken van gebruik in de praktijk, de kwetsbaarheid ontbreekt op de KEV-lijst van CISA en de enige openbare exploit is de kernelCTF-inzending. Maar "nog geen misbruik" is een tijdschema, geen eindoordeel. Openbare kernel-LPE's worden routinematig tot wapen gemaakt zodra onderzoekers of aanvallers de techniek namaken, en de details liggen nu open en bloot. De veilige aanname is dat er een werkende exploit zal circuleren, dus behandel de patch als tijdgevoelig in plaats van optioneel. Dit patroon — een snelbewegend lek waar verdedigers tegen moeten racen — wordt de norm naarmate aanvallers meer van het werk automatiseren, een trend die we behandelden in beveiliging van AI-agents en de prompt-injectiecrisis.

Veelgestelde vragen

Moet ik herstarten na het patchen van Bad Epoll?

Ja, tenzij je live kernel-patching gebruikt. Het installeren van het bijgewerkte kernelpakket zet de fix klaar, maar de kwetsbare code blijft draaien totdat je naar de nieuwe kernel opstart. Livepatch (Ubuntu) of kpatch (RHEL) kunnen de fix op ondersteunde versies toepassen op een draaiende kernel als je niet meteen kunt herstarten.

Is mijn server getroffen als hij een LTS-distributie draait?

Mogelijk. Wat telt is de kernelversie, niet de marketing van de distributie. Een LTS-release kan nog steeds een kernel 6.4 of nieuwer meeleveren, en dat is het getroffen bereik. Voer uname -r uit en raadpleeg het advies van je distributie over CVE-2026-46242.

Lopen Android-telefoons risico?

Alleen die met een kernel 6.4 of nieuwer. Apparaten die nog op 6.1-gebaseerde kernels draaien, waaronder sommige huidige telefoons, zijn niet getroffen. Waar een apparaat binnen bereik valt, wacht op de beveiligingsupdate van de leverancier en installeer die.

Hoe ernstig is dit vergeleken met een exploit op afstand?

Op zichzelf heeft een lokaal lek een aanvaller nodig die al een voet tussen de deur heeft, dus het scoort lager dan een lek voor uitvoering van code op afstand. In de praktijk is het de standaard volgende stap na een eerste inbraak, en daarom zijn lokale root-lekken gewild en daarom blijft snel patchen toch belangrijk.

Bronnen

• The Hacker News — New "Bad Epoll" Linux Kernel Flaw Lets Unprivileged Users Gain Root: primaire verslaggeving over CVE-2026-46242, de use-after-free-oorzaak in epoll, het race-venster van ongeveer zes instructies, de getroffen 6.4+-kernels, de fix-commit a6dc643c6931, de ontdekking door Jaeyoung Chung via Google kernelCTF en het ontbreken van gebruik in het wild.
• CISA Known Exploited Vulnerabilities Catalog: referentie om te bevestigen of CVE-2026-46242 is toegevoegd als actief misbruikte kwetsbaarheid.
• bad-epoll proof-of-concept repository: de openbare kernelCTF-exploitcode die de rechtenescalatie demonstreert.