Am 16. September 2026 hat AWS das Security Bulletin 2026-113-AWS veröffentlicht (CVE-2026-86831, Einstufung „Important“). Es beschreibt eine Schwachstelle im EKS Network Policy Agent, über die NetworkPolicy-Regeln zwischen Namespaces unter bestimmten Bedingungen umgangen werden können. Wer auf Amazon EKS Kubernetes Network Policies mit dem nativen VPC-CNI-Enforcement nutzt, sollte jetzt die Add-on-Version prüfen. Die gute Nachricht: Der Fix ist bereits seit dem 22. Juli 2026 verfügbar.
Kubernetes erlaubt standardmäßig jede Pod-zu-Pod-Kommunikation im Cluster, unabhängig vom Namespace. Mit NetworkPolicy-Objekten schränken Teams diesen Datenverkehr ein. Sie wirken als Namespace-scoped Firewall auf Layer 3 und 4 und steuern Ingress- und Egress-Traffic anhand von Pod- und Namespace-Selektoren.
Auf Amazon EKS setzt seit VPC CNI v1.14.0 ein eigener Network Policy Agent diese Regeln durch. Die Architektur besteht aus zwei Teilen:
policyendpoints.networking.k8s.aws bereit.aws-eks-nodeagent im aws-node-DaemonSet auf jedem Worker-Node. Er liest die PolicyEndpoints und setzt die Regeln über eBPF-Programme durch, die am host-seitigen veth-Interface jedes Pods hängen.Dieser Ansatz ist performant und tief im Linux-Kernel verankert. Er setzt aber voraus, dass der Agent Pods verschiedener Namespaces zuverlässig auseinanderhalten kann. Genau hier liegt das Problem.
Laut Bulletin setzt der aws-network-policy-agent in Versionen vor v1.4.0 Pod-Identifikatoren aus Pod-Name und Namespace-Name zusammen, getrennt durch einen Bindestrich (-). Der Bindestrich ist aber sowohl in Pod- als auch in Namespace-Namen erlaubt.
Das führt zu Kollisionen. Ein Pod frontend im Namespace app-prod und ein Pod frontend-app im Namespace prod ergeben beide frontend-app-prod. Der Agent kann die beiden nicht mehr sicher unterscheiden. NetworkPolicy-Regeln für einen Namespace können dadurch fälschlich auf Pods eines anderen Namespace wirken oder dort ausbleiben.
Für einen gezielten Angriff braucht ein Angreifer oder eine kompromittierte Workload das Recht, Pods in einem passenden Namespace anzulegen. Außerdem muss er den Pod-Namen frei wählen können. Pods aus Deployments tragen zufällige Hash-Suffixe, deshalb sind Kollisionen dort unwahrscheinlich. Realistischer sind gezielt benannte Einzel-Pods oder StatefulSets. Gelingt die Kollision, kann der Angreifer möglicherweise Netzwerkzugriff auf Pods erhalten, die durch NetworkPolicies eigentlich abgeschirmt sind. Die Schwachstelle stellt damit die Namespace-Isolation als Sicherheitsgrenze infrage, ein Fundament vieler Multi-Tenant- und Compliance-Architekturen auf EKS.
Betroffen sind nur Cluster, in denen die Network-Policy-Unterstützung des VPC CNI aktiviert ist. Wer Network Policies nicht über das VPC CNI durchsetzt, ist nicht betroffen. Auf Fargate-Pods läuft der Network Policy Agent nicht.
AWS nennt im Bulletin:
Der Fix wird erst mit VPC CNI v1.22.4 ausgeliefert, das den Agent v1.4.0 mitbringt. Behandeln Sie deshalb alle VPC-CNI-Versionen ab v1.14.0 und vor v1.22.4 als betroffen, auch v1.22.3. Die Untergrenze v1.14.0 ergibt sich daraus, dass diese Version die native Network-Policy-Unterstützung eingeführt hat. Cluster auf v1.13.x oder älter sind von dieser Lücke nicht betroffen, sollten aber aus anderen Gründen dringend aktualisiert werden.
Alle drei Images im aws-node-DaemonSet, also CNI, Init-Container und Network Policy Agent, zeigt dieser Befehl:
kubectl describe daemonset aws-node -n kube-system \
| grep Image | cut -d "/" -f 2-3Ein gepatchter Cluster liefert:
amazon-k8s-cni-init:v1.22.4
amazon-k8s-cni:v1.22.4
amazon/aws-network-policy-agent:v1.4.0Beim EKS Managed Add-on liefert die AWS CLI die Version:
aws eks describe-addon \
--cluster-name <cluster-name> \
--addon-name vpc-cni \
--query addon.addonVersion \
--output textOb Network Policies aktiviert sind, prüfen Sie so:
# Managed Add-on: Konfiguration enthält "enableNetworkPolicy": "true"
aws eks describe-addon \
--cluster-name <cluster-name> \
--addon-name vpc-cni \
--query addon.configurationValues \
--output text
# Direkt im DaemonSet: Argument --enable-network-policy=true
kubectl get daemonset aws-node -n kube-system \
-o jsonpath='{.spec.template.spec.containers[?(@.name=="aws-eks-nodeagent")].args}'Laut den Release Notes zu v1.22.4 ist das Release bei aktivierter Network Policy nicht abwärtskompatibel, weil sich das interne Format der Pod-Identifikatoren geändert hat. Beim Upgrade wird der bestehende Enforcement-Zustand automatisch migriert. Nach einem späteren Downgrade greift die Enforcement für Pods, die vor dem Rollback erstellt wurden, jedoch erst wieder, wenn deren Nodes ersetzt wurden.
Ein Rollback bedeutet in der Praxis also Node-Replacement. Planen Sie das in Ihr Change-Fenster ein und testen Sie das Upgrade zuerst in einer Nicht-Produktionsumgebung.
AWS empfiehlt das Upgrade auf Amazon VPC CNI ≥ v1.22.4 und aws-network-policy-agent ≥ v1.4.0. Aktualisieren Sie VPC CNI dabei jeweils nur um eine Minor-Version. Von v1.20.x geht es also zunächst auf v1.21.x und dann auf v1.22.x.
Ermitteln Sie zuerst den verfügbaren Build für Ihre Kubernetes-Version:
aws eks describe-addon-versions \
--addon-name vpc-cni \
--kubernetes-version <k8s-version> \
--query 'addons[].addonVersions[].addonVersion' \
--output textStarten Sie dann das Upgrade. PRESERVE behält manuelle Anpassungen am aws-node-DaemonSet bei. OVERWRITE würde sie zurücksetzen.
aws eks update-addon \
--cluster-name <cluster-name> \
--addon-name vpc-cni \
--addon-version <v1.22.4-eksbuild.X> \
--resolve-conflicts PRESERVEWer das Add-on über IaC oder GitOps verwaltet, sollte die Version dort anheben, damit der nächste Sync das Upgrade nicht wieder zurückdreht.
Aktualisieren Sie alle drei Images, nicht nur das CNI-Image, sonst bleibt der verwundbare Agent aktiv. Nutzen Sie außerdem --reuse-values, damit bestehende Einstellungen wie die Network-Policy-Aktivierung nicht auf Defaults zurückfallen:
helm repo update eks
helm upgrade aws-vpc-cni eks/aws-vpc-cni \
--namespace kube-system \
--version <Chart-Version für App v1.22.4> \
--reuse-values \
--set image.tag=v1.22.4 \
--set init.image.tag=v1.22.4 \
--set nodeAgent.image.tag=v1.4.0Prüfen Sie anschließend mit dem Befehl oben, dass alle drei Images auf dem neuen Stand sind.
AWS nennt als Workaround, keine Bindestriche in Namespace-Namen zu verwenden. Ohne Bindestrich im Namespace ist der Identifikator eindeutig. In bestehenden Clustern ist das selten kurzfristig umsetzbar, denn ein Namespace lässt sich nicht umbenennen, nur neu anlegen.
Pragmatischer sind zwei Zwischenschritte. Prüfen Sie erstens, ob im Cluster aktuell Kollisionen existieren. Der folgende Befehl bildet die Identifikatoren nach dem im Bulletin beschriebenen Schema nach und gibt Duplikate aus. Er erfasst nur aktuell laufende Pods:
kubectl get pods -A -o json \
| jq -r '.items[] | "\(.metadata.name)-\(.metadata.namespace)"' \
| sort | uniq -dVerhindern Sie zweitens, dass bis zum Upgrade neue Namespaces mit Bindestrich entstehen, zum Beispiel mit einer ValidatingAdmissionPolicy:
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
name: deny-hyphenated-namespaces
spec:
failurePolicy: Fail
matchConstraints:
resourceRules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE"]
resources: ["namespaces"]
validations:
- expression: "!object.metadata.name.contains('-')"
message: "Bis zum VPC-CNI-Upgrade (CVE-2026-86831) sind keine Bindestriche in Namespace-Namen erlaubt."
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
name: deny-hyphenated-namespaces
spec:
policyName: deny-hyphenated-namespaces
validationActions: [Deny]Achtung: Die Policy blockiert auch Add-ons und Tools, die eigene Namespaces mit Bindestrich anlegen. Setzen Sie sie gezielt und nur temporär ein. Das Upgrade bleibt die eigentliche Lösung.
Die Schwachstelle trifft vor allem Cluster, in denen Namespaces Teams, Mandanten oder Umgebungen voneinander trennen. Wer Produktions- und Staging-Workloads per NetworkPolicy isoliert oder Kunden-Workloads in einem Shared Cluster betreibt, verlässt sich darauf, dass diese Grenze hält.
Ob ein Cluster ausnutzbare Kollisionen aufweist, hängt von den konkreten Pod- und Namespace-Namen ab. AWS macht keine Angaben dazu, ob die Schwachstelle bereits ausgenutzt wurde. Priorisieren Sie das Upgrade deshalb unabhängig davon, ob Ihr Kollisionscheck etwas findet.
Wer mehrere Cluster betreibt, etwa im Rahmen einer AWS Landing Zone, sollte die Add-on-Stände zentral inventarisieren und das Upgrade in den regulären Change-Management-Prozess einspeisen. Gehen Sie nicht davon aus, dass alle Cluster auf demselben Stand sind.
Worauf Sie bei EKS-Upgrades und dem neuen Version Rollback generell achten sollten, beschreibt unser Beitrag Kubernetes v1.37 „Garhwal": Was EKS-Betreiber vor dem nächsten Upgrade wissen müssen. Beachten Sie dabei: Das Rollback der Control Plane hilft beim CNI-Downgrade-Problem oben nicht. Wie Identitäten im Cluster zur Angriffsfläche werden, zeigt unser Artikel Die unsichtbare Bedrohung: Warum Machine Identities Ihre größte Cloud-Sicherheitslücke sind.
Das Upgrade selbst ist meist unkompliziert, und Prüfung und Planung sind überschaubar. Nicht lohnen sollte sich dagegen, abzuwarten und darauf zu hoffen, dass die eigenen Namespace-Namen keine Kollisionen erzeugen.