# Linux-containers: wanneer de isolatie niet meer houdt

> Een nieuw lek in de Linux-kernel laat een proces uit een gewone Docker- of Kubernetes-container ontsnappen naar de host. Het beveiligingsbedrijf depthfirst besluit dat containers geen veiligheidsgrens meer zijn. Wat dat betekent voor een kmo die containers gebruikt.

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.

**In het kort**

1. CVE-2026-80521 is een use-after-free in de afvalverwerking van AF_UNIX-sockets, die vanuit een standaardcontainer bereikbaar is; de upstream-correctie dateert van 6 augustus 2026, maar Ubuntu 26.04 en 24.04 hadden op 1 oktober nog geen gecorrigeerde kernel.
2. Depthfirst telt 5.976 kernel-CVE's tussen 1 januari en 16 september 2026, van 249 in januari tot 1.650 in augustus; de kernelontwikkelaars kennen wel aan bijna elke bugfix een CVE toe, wat het aantal opdrijft.
3. AWS schreef al in november 2025 dat het containers niet als veiligheidsgrens beschouwt en ze niet gebruikt om klanten van elkaar te scheiden; voor code die je niet vertrouwt, is een virtuele machine of micro-VM de veiligere keuze.


*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](https://depthfirst.com/research/containers-are-no-longer-safe). 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](https://ubuntu.com/security/CVE-2026-80521), 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](https://docs.kernel.org/process/cve.html) 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](https://aws.amazon.com/security/security-bulletins/AWS-2025-024/), 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](https://firecracker-microvm.github.io/), 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.
{.dialoog}

### 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]

[^1]: 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.

[^2]: 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.

[^3]: 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.