Direct naar de inhoud
Cybersecurity

Ubuntu container escape via CVE-2026-80521

Ubuntu container escape

Beveiligingsonderzoekers waarschuwen voor een nieuwe route naar Ubuntu container escape. Een kwetsbaarheid in de Linux kernel (CVE-2026-80521) kan, wanneer hij niet is gepatcht, vanuit een container de isolatie doorbreken en uiteindelijk rootrechten op de host opleveren. DepthFirst heeft bovendien exploitcode vrijgegeven, gericht op Ubuntu 26.04.

Hoewel er (volgens de beschikbare informatie) geen bevestigde aanvallen bekend zijn en de fout niet voorkomt in CISA’s Known Exploited Vulnerabilities-catalogus, is de praktische impact groot: de aanval maakt gebruik van gewone systeemcalls die containers mogen doen. Daarmee valt het argument “een container is veilig genoeg” voor dit specifieke type kwetsbaarheid weg.

Wat is CVE-2026-80521 en waarom is het zo gevaarlijk?

CVE-2026-80521 is een use-after-free in het AF_UNIX socket subsysteem van de Linux kernel. De kwetsbaarheid bevindt zich in de garbage collector van AF_UNIX sockets, een onderdeel dat de opruimlogica bevat voor bestandsdescriptoren die tussen processen worden uitgewisseld.

AF_UNIX sockets worden standaard gebruikt voor communicatie tussen lokale processen. In containeromgevingen zijn deze sockets doorgaans toegestaan via standaard profielen, waardoor de kwetsbaarheid vanuit binnen de container kan worden bereikt.

Hoe werkt de race condition precies?

De kern van het probleem is een race condition in het garbage collector mechanisme. Daardoor kan de collector nieuwe referenties “zien” voordat de data die erbij hoort daadwerkelijk in de juiste queue is geplaatst.

Als de garbage collector in dat nauwe tijdsvenster draait, kan hij een deel van een groep gekoppelde sockets vrijgeven zonder een verwijzing uit een interne lijst correct te verwijderen. Bij een volgende garbage-collectie volgt het systeem die verwijzing in vrijgegeven geheugen, wat de basis vormt voor de escalatie.

Welke Ubuntu versies lopen risico?

Upstream is de kwetsbaarheid opgelost op 6 augustus. Toch heeft Ubuntu volgens het beveiligingsonderzoek de patch nog niet doorgestuurd naar de getroffen LTS-releases. Dat betekent dat systemen op basis van een kwetsbare kernel nog steeds risico lopen.

Concreet gaat het om:

  • Ubuntu 26.04 LTS: patch ontbreekt; security tracker markeert het pakket als “vulnerable, work in progress”.
  • Ubuntu 24.04 LTS: kwetsbaar via nieuwere kernelpakketten, waaronder varianten voor cloudomgevingen.
  • Ubuntu 22.04 LTS: eveneens kwetsbaar via nieuwere kernelpakketten, inclusief die voor AWS-, Azure- en GCP-workloads.

Voor geen van deze getroffen releases is (voor zover bekend in de broninformatie) een fix gepubliceerd.

Waarom kan dit de container-isolatie doorbreken?

Een belangrijk detail is dat de exploit de kernel bereikt via gewone systeemaanroepen die containers doorgaans mogen uitvoeren. Daardoor omzeilt de aanval de mechanismen waarmee containers vaak worden afgeschermd:

  • Namespace isolatie wordt niet genoeg afgedekt tegen deze kernelbug.
  • cgroup-limieten beperken wel resources, maar stoppen de escalatie niet.
  • seccomp filtering is in dit scenario niet voldoende, omdat de benodigde paden binnen de toegestane calls vallen.

De onderzoekers stellen daarom dat containers in dit soort gevallen niet als betrouwbare security boundary gezien moeten worden.

Exploitcode vrijgegeven: wat weten we al?

DepthFirst publiceerde exploitcode die is gericht op Ubuntu 26.04. Dat verhoogt de praktische haalbaarheid van misbruik, omdat aanvallers nu niet hoeven te experimenteren op basis van alleen theoretische details.

Daarnaast meldt de broninformatie dat de kwetsbaarheid niet staat op de Known Exploited Vulnerabilities-lijst van CISA en dat er geen bevestigde aanvallen bekend zijn die hiervan gebruikmaken.

Ook is er (volgens de beschikbare gegevens) geen tijdelijke mitigatie of workaround gepubliceerd door DepthFirst of door Ubuntu.

Welke kernelversies zijn gepatcht?

De upstream fix is geland in de mainline kernel in de lijn van kernel 7.2. In de stable branches is ook een fix toegevoegd, genoemd als kernel 7.1.10.

De kwetsbare code werd geïntroduceerd in kernel 6.10 en is teruggeport naar stable branches 6.1 en 6.6.

Organisaties die op een beïnvloede kernel draaien, kunnen daarom in de kern sturen op: updaten naar een versie waarin de upstream patch is verwerkt of de fix direct toepassen waar dat in hun distributieproces past.

Beperken van risico: wat adviseert DepthFirst?

Omdat er geen tijdelijke workaround is, adviseert DepthFirst een structurele isolatie-aanpak. Hun aanbeveling is om onvertrouwde workloads niet in standaard containers te draaien, maar in microVM-isolatie zoals:

  • Firecracker
  • Kata Containers

Het idee daarachter: elke workload draait met een eigen kernel. Daarmee wordt het type aanval dat afhankelijk is van kernelgedrag veel lastiger of onbruikbaar, omdat er minder (of geen) gedeelde kernel-context is.

Hoe werd de kwetsbaarheid gevonden?

DepthFirst beschrijft dat een AI-model, genoemd als dfs-large1, hielp bij het ontdekken van de fout. Het model zou de kwetsbaarheid hebben geïdentificeerd, waarna een menselijk testkader verder hielp met het valideren van het probleem.

Daarnaast noemt de broninformatie dat DepthFirst een Google kernelCTF-slot won met het exploit-werk op 24 juli, en dat de bug vervolgens is gerapporteerd aan het kernel security team op 5 augustus.

In de timeline meldt DepthFirst ook dat kernel maintainers aangaven dat een OpenAI-onderzoeker de bug onafhankelijk had gerapporteerd. In de CVE-commit wordt bovendien een kernel-exploit onderzoeker (Kyle Zeng) vermeld als reporter.

Betekenis voor teams: containerveiligheid opnieuw beoordelen

Deze publicatie past in een bredere trend van kernelkwetsbaarheden die containerescapes mogelijk maken. De bron noemt dat er in 2026 meerdere fouten zijn opgedoken met vergelijkbare gevolgen, waaronder issues die eerder al root-escalatie op de host konden faciliteren.

Voor beveiligingsteams is de les helder: zelfs wanneer een omgeving containertechnologie gebruikt en seccomp, namespaces of cgroups aanwezig zijn, kan een kernelbug het volledige isolatiemodel ondermijnen. Daarom is het verstandig om Ubuntu container escape als scenario actief mee te nemen in risicobeoordelingen, patchprocessen en architectuurkeuzes.

Praktische checklist om nu actie te nemen

  • Inventariseer welke Ubuntu hosts en nodes draaien op kernels die mogelijk onder de getroffen reeks vallen (22.04/24.04/26.04, afhankelijk van de kernelpakketten).
  • Controleer of de kernelversie een upstream of stable fix bevat (mainline 7.2 en stable 7.1.10 worden genoemd).
  • Implementeer isolatie voor onvertrouwde workloads: overweeg microVM’s wanneer patching niet snel haalbaar is.
  • Volg updates van Ubuntu’s security tracker voor distributie-specifieke release-informatie.

Door deze stappen te combineren, verklein je de kans dat een containeromgeving een opstap wordt naar hostcompromis.

Conclusie

De vrijgegeven exploitcode rond CVE-2026-80521 maakt duidelijk dat Ubuntu container escape in de praktijk haalbaar kan worden wanneer de kernel niet gepatcht is. Hoewel er (nog) geen bevestigde aanvallen bekend zijn, is de combinatie van een kerneluse-after-free, de bereikbaarheid vanuit containers en het bypassen van typische containerbegrenzingen reden genoeg om direct te handelen.

Werk daarom je patch- en isolatiestrategie bij, en behandel containers niet automatisch als sluitende security boundary tegen kernel-level kwetsbaarheden.

Bron: https://thehackernews.com/2026/09/exploit-released-for-unpatched-ubuntu.html