containerd CVE-2026-46680: Lücke umgeht Kubernetes-Richtlinie runAsNonRoot und ermöglicht Root-Container

In der Container-Runtime containerd ist eine als hoch eingestufte Sicherheitslücke bekannt geworden, die eine zentrale Schutzmaßnahme von Kubernetes aushebelt. Die Schwachstelle mit der Kennung CVE-2026-46680 (CVSS 7.8, High) erlaubt es Angreifern, die Richtlinie runAsNonRoot zu umgehen und Container trotz erzwungener Non-Root-Vorgabe mit Root-Privilegien (UID 0) auszuführen. Damit wird eine fundamentale Sicherheitsgrenze überwunden. Die zugehörigen Patch-Releases wurden am 20. und 21. Mai 2026 veröffentlicht. Betroffen sind Docker-Umgebungen, Kubernetes-Cluster sowie verwaltete Dienste wie Google Kubernetes Engine, Azure Kubernetes Service und Amazon EKS.

Die Schwachstelle: Type Confusion bei der User-Auflösung

Der Kern des Problems liegt in der Art, wie containerd numerische User-Direktiven verarbeitet. Wird ein Container mit einer numerischen User-Angabe gestartet, die nicht als 32-Bit-Integer geparst werden kann – etwa weil der Wert größer als ein 32-Bit-Integer ist –, interpretiert containerd diese Angabe fälschlicherweise als Benutzernamen statt als numerische UID. Diese Verwechslung von Datentypen ist als CWE-843 (Type Confusion) klassifiziert.

Den eigentlichen Angriff ermöglicht erst ein manipuliertes Container-Image: Enthält die /etc/passwd-Datei im Image einen passend präparierten Eintrag, lässt sich der vermeintliche Benutzername auf Root auflösen. Der Container startet dann mit der UID 0 und damit als Root – obwohl die Kubernetes-Richtlinie runAsNonRoot genau das verhindern soll. Diese Richtlinie ist in vielen Umgebungen eine tragende Säule der Workload-Isolation, weshalb ihre Umgehung eine kritische Sicherheitsgrenzüberschreitung darstellt.

Bin ich betroffen?

Betroffen sind nach aktuellem Stand die folgenden containerd-Versionsreihen:

1. containerd 1.7.27 bis 1.7.31
2. containerd 2.0.4 bis 2.0.8
3. containerd 2.1.0 bis 2.2.3
4. containerd 2.3.0

Besonders exponiert sind Kubernetes-Cluster, die sich zur Durchsetzung von Non-Root-Ausführung auf runAsNonRoot verlassen, sowie Docker-Umgebungen mit einer betroffenen containerd-Version. Auch verwaltete Kubernetes-Angebote der großen Cloud-Anbieter (GKE, AKS, Amazon EKS) können betroffen sein, da sie containerd als Runtime einsetzen. Welche containerd-Version lokal installiert ist, lässt sich über die Kommandozeile prüfen:

containerd --version
# alternativ auf einem Kubernetes-Node:
kubectl get nodes -o wide

Liefert die Prüfung eine der oben genannten Versionen, ist das System angreifbar und sollte umgehend aktualisiert werden.

Wie behebe ich das?

Das Projekt hat korrigierte Versionen über mehrere Patch-Releases bereitgestellt. Empfohlen wird ein sofortiges Update auf eine der folgenden oder eine höhere Version:

1. containerd 1.7.32 oder höher
2. containerd 2.0.9 oder höher
3. containerd 2.2.4 oder höher
4. containerd 2.3.1 oder höher

Lässt sich ein Update nicht sofort einspielen, stehen zwei Mitigationen zur Verfügung: Zum einen kann im securityContext des Pods ein numerischer runAsUser erzwungen werden, sodass die fehlerhafte Namensauflösung umgangen wird. Zum anderen ist der Einsatz von Kubernetes in Version 1.34 oder höher als Gegenmaßnahme genannt.

securityContext:
  runAsNonRoot: true
  runAsUser: 1000

Wer verwaltete Kubernetes-Dienste nutzt, sollte die Hinweise des jeweiligen Anbieters (GKE, AKS, Amazon EKS) zur Aktualisierung der Node-Images beachten, da die containerd-Version dort über die Plattform bereitgestellt wird.

Was bedeutet das für Unternehmen?

Für Organisationen, die auf die Container-Isolation von Kubernetes setzen, ist die Lücke als kritisch einzustufen. Die Umgehung von runAsNonRoot kann unautorisierten Root-Zugang ermöglichen und damit den Weg zu Systemkompromittierung, Datenverlust und Supply-Chain-Angriffen ebnen. Besonders hoch ist das Risiko in Multi-Tenant-Umgebungen und überall dort, wo nicht vertrauenswürdige Workloads oder Images aus externen Quellen ausgeführt werden – denn der Angriff setzt ein manipuliertes Image voraus.

IT-Verantwortliche sollten das Update entsprechend priorisieren: Eine Inventarisierung der eingesetzten containerd-Versionen über alle Cluster-Nodes hinweg ist der erste Schritt, gefolgt vom Einspielen der gepatchten Versionen. Bis dahin senkt das Erzwingen eines numerischen runAsUser das Risiko spürbar. Da die Schwachstelle eine grundlegende Sicherheitsannahme von Kubernetes betrifft, sollte sie nicht als reines Konfigurationsdetail behandelt, sondern in den regulären Patch-Prozess für sicherheitskritische Infrastruktur aufgenommen werden.

Quellen

Weiterführende Informationen finden sich in der GitLab Advisory Database (GLAD) zu CVE-2026-46680, bei DailyCVE sowie in den Release-Notes der gepatchten Versionen containerd v1.7.32, containerd v2.2.4 und containerd v2.3.1.