Linux-containers: wanneer de isolatie niet meer houdt
Een lek in de Linux-kernel, CVE-2026-80521, laat een proces zonder speciale rechten ontsnappen uit een standaardcontainer van Docker of Kubernetes en root worden op de server eronder. Het beveiligingsbedrijf depthfirst vond het met een eigen AI-model en publiceerde op 22 september 2026 een werkende exploit. Volgens Ubuntu waren versies 26.04 en 24.04 op 1 oktober nog kwetsbaar. Depthfirst besluit dat containers geen betrouwbare veiligheidsgrens meer zijn, en raadt voor onbetrouwbare code micro-VM’s aan, zoals Firecracker of Kata Containers.
Of: waarom een eigen voordeur nog geen eigen huis is
Een container is een van de handigste uitvindingen van de voorbije tien jaar. Je pakt een programma in met alles wat het nodig heeft, je zet het op een server, en het draait, naast tientallen andere, elk in zijn eigen hokje. Dat hokje voelt als een muur. Het beveiligingsbedrijf depthfirst publiceerde op 22 september 2026 een onderzoek met een titel die weinig ruimte laat: containers zijn geen veiligheidsgrens meer. We moeten, schrijft het, aannemen dat aanvallers eruit kunnen ontsnappen wanneer ze willen.
Container escape in Linux: wat er gebeurde
Het lek
Het concrete bewijs heet CVE-2026-80521. Het is een fout in de manier waarop de Linux-kernel opruimt na AF_UNIX-sockets, het mechanisme waarmee programma’s op dezelfde machine met elkaar praten en elkaar bestanden doorgeven. Onder bepaalde omstandigheden geeft de kernel geheugen vrij dat nog in gebruik is, een zogenaamde use-after-free. Wie dat goed timet, kan het geheugen van de kernel aanpassen.
Het venijn zit in de plaats. AF_UNIX-sockets zijn in de standaardinstellingen van Docker en Kubernetes gewoon toegelaten, omdat heel veel software ze nodig heeft. Een proces zonder speciale rechten, in een container zoals ze standaard opgezet wordt, kan het lek dus bereiken. Depthfirst toont dat zo’n proces eruit kan breken en een root-shell krijgt op de server zelf, langs de namespaces, de cgroups en de seccomp-filters heen die de container moesten afschermen.
Depthfirst zegt het lek gevonden te hebben met zijn eigen AI-model voor het opsporen van kwetsbaarheden, en zette de exploit op GitHub. De correctie in de kernel dateert van 6 augustus 2026. Volgens de pagina van Ubuntu, bijgewerkt op 1 oktober, waren versies 26.04 en 24.04 toen nog kwetsbaar; 22.04 en 20.04 zijn niet getroffen.1
De cijfers achter de stelling
Eén lek maakt nog geen trend. Depthfirst brengt er twee cijferreeksen bij. Tussen 1 januari en 16 september 2026 telt het 5.976 verschillende CVE’s voor de Linux-kernel, van 249 in januari tot 1.650 in augustus. En van 36 lekken die via kernelCTF, het beloningsprogramma van Google voor aanvallen op de kernel, bekend werden, waren er 13 bereikbaar via onderdelen die een container standaard krijgt.
Dat eerste cijfer verdient een kanttekening. De kernelontwikkelaars schrijven zelf in hun documentatie dat ze aan elke bugfix een CVE toekennen die ze vinden, omdat bijna elke fout in de kernel misbruikt zou kunnen worden, ook als dat bij de correctie niet duidelijk is. Het aantal CVE’s meet dus ook de ijver van de boekhouding, niet alleen het aantal echte inbraakroutes.2 Het tweede cijfer is daarom het interessantste: ruim een derde van de aangetoonde aanvallen was bereikbaar vanuit een gewone container.
Het is niet echt nieuw
Wie in de sector werkt, hoort het met een zekere herkenning. AWS schreef in november 2025, in een beveiligingsbericht over lekken in runc, de software die containers start, letterlijk dat het containers niet als veiligheidsgrens beschouwt en ze niet gebruikt om klanten van elkaar te scheiden. Daarvoor bouwde AWS Firecracker, een kleine virtuele machine die volgens AWS in minder dan 125 milliseconden opstart, met minder dan 5 MiB extra geheugen, en waarop onder meer Lambda draait. Nieuw is niet de stelling. Nieuw is dat depthfirst ze met een werkende exploit en een AI-model onderbouwt.
Waarom een container geen huis is
Het beste beeld is een appartementsgebouw. Elke container is een appartement, met een eigen voordeur en een eigen sleutel. Maar alle appartementen delen dezelfde trappenhal, dezelfde leidingen en dezelfde conciërge met de loper: de kernel. Wie in zijn eigen appartement een manier vindt om de conciërge iets te laten doen wat hij niet mag, staat met de loper in de trappenhal, voor alle deuren tegelijk.
Een virtuele machine is een ander huis, met een eigen conciërge. Een micro-VM is een tiny house: klein, snel neergezet, maar met eigen muren. En depthfirst zegt eigenlijk dit: de conciërge van het appartementsgebouw is niet slechter geworden, maar er lopen nu mensen rond met een machine die zijn zwakke plekken sneller vindt dan hij ze kan herstellen.
Kmo-Kristof: Onze website, onze boekhouding en de chatbot van de stagiair draaien allemaal in Docker. Dan zit alles apart.
Security-Sofie: Apart van elkaar, ja. Niet apart van de kernel.
Kmo-Kristof: En wat doet de kernel?
Security-Sofie: Alles. Daarom.
Wat het betekent voor je zaak
Containers duiken in een kleine zaak vaker op dan je denkt: op een gehuurde server met Docker, op een NAS met een containerbeheerder, in de installatie van Nextcloud All-in-One, of in de testomgeving van een developer. De stelling van depthfirst maakt die niet onbruikbaar. Ze verandert wel waarvoor je ze gebruikt.
- Containers blijven goed om je eigen software te ordenen: programma’s apart houden, eenvoudig bijwerken, verhuizen naar een andere server. Daar zijn ze voor gemaakt.
- Containers zijn geen kluis voor code die je niet vertrouwt. Draai je software van derden, code die klanten aanleveren, of code die een AI-agent schrijft en uitvoert, op dezelfde server als je klantgegevens, kies dan een aparte virtuele machine of een micro-VM.
- Werk de kernel bij, niet alleen de images. Een nieuwe versie van een container-image verandert niets aan de kernel van de server eronder. Die werk je bij met de updates van je besturingssysteem, en vaak pas na een herstart.
- Vraag het je hostingbedrijf. Gedeelde hosting of beheerde containers: vraag of klanten van elkaar gescheiden worden met containers of met virtuele machines.
Ik vind die laatste vraag de nuttigste van allemaal. AWS gaf het antwoord voor zichzelf al in 2025. Het is redelijk om het ook aan je eigen leverancier te vragen.
De deur en het huis
Een container heeft een voordeur, en dat was altijd een goede reden om er iets in te stoppen. Wat depthfirst eigenlijk zegt, is dat een eigen voordeur nog geen eigen huis is. Zolang alle deuren op dezelfde trappenhal uitkomen, hangt je veiligheid af van de conciërge. En die heeft het, met 5.976 genoteerde fouten in negen maanden, behoorlijk druk.3
De Hacker News meldde ook Ubuntu 22.04 als getroffen. De pagina van Ubuntu zelf, die we hier volgen, zegt van niet. Ubuntu geeft het lek de prioriteit „medium”, terwijl de CVSS-score 7,8 op 10 is: twee schalen die niet hetzelfde meten. CVSS beschrijft hoe erg een lek technisch is, de prioriteit van Ubuntu hoe dringend het voor de eigen gebruikers is. ↑
Dat beleid heeft een prijs: beheerders krijgen een stroom aan meldingen te verwerken. Het heeft ook een logica: een fout die vandaag onschuldig lijkt, blijkt morgen een inbraakroute. Wie elke fout noteert, mist er geen. Wie elke melding moet lezen, mist er wel. ↑
Om eerlijk te zijn tegenover de conciërge: een groot deel van die fouten zal nooit tot een aanval leiden. Het probleem is dat je niet op voorhand weet welk deel. ↑
Bronnen
- Containers Are No Longer a Security Boundary (depthfirst, 22 september 2026)
- CVE-2026-80521 (Ubuntu Security, bijgewerkt op 1 oktober 2026)
- Security Bulletin AWS-2025-024, runc (Amazon Web Services, november 2025)
- CVEs, The Linux Kernel documentation
- Firecracker (Amazon Web Services)
- Exploit Released for Unpatched Ubuntu Linux Flaw Enabling Host-Root Container Escape (The Hacker News, september 2026)