Kubernetes Security Vulnerabilities in 2026: IngressNightmare, runc Escapes & RBAC Hardening GuideVulnérabilités Sécurité Kubernetes en 2026 : IngressNightmare, Évasions runc & Guide de Durcissement RBAC

Kubernetes powers over 5.6 million developers worldwide and underpins the majority of cloud-native production infrastructure. In 2026, it remains as powerful as ever — and as dangerous to misconfigure. Eight CVEs have already been published against Kubernetes this year, with an average CVSS score of 7.5. More critically, 89% of organizations reported a Kubernetes-related security incident in the past year, and a class of container escape vulnerabilities in runc — the runtime that underpins Docker, containerd, and Kubernetes nodes — rewrote the industry's assumptions about container isolation.

Kubernetes alimente plus de 5,6 millions de développeurs dans le monde et constitue l'épine dorsale de la majorité de l'infrastructure cloud-native en production. En 2026, il reste aussi puissant que jamais — et aussi dangereux en cas de mauvaise configuration. Huit CVE ont déjà été publiées contre Kubernetes cette année, avec un score CVSS moyen de 7,5. Plus critique encore, 89% des organisations ont signalé un incident de sécurité lié à Kubernetes dans l'année écoulée, et une classe de vulnérabilités d'évasion de container dans runc — le runtime qui sous-tend Docker, containerd et les nœuds Kubernetes — a remis en question les hypothèses de l'industrie sur l'isolation des containers.

This guide covers the most critical Kubernetes security vulnerabilities of 2025-2026 — IngressNightmare, runc container escapes, RBAC misconfigurations — with verified data, real CVE analysis, and a practical hardening checklist for development teams running containers in production.

Ce guide couvre les vulnérabilités de sécurité Kubernetes les plus critiques de 2025-2026 — IngressNightmare, évasions de containers runc, mauvaises configurations RBAC — avec des données vérifiées, une analyse des CVE réelles et une checklist de durcissement pratique pour les équipes de développement qui font tourner des containers en production.

IngressNightmare: The CVE That Can Hand Attackers Your Entire Cluster

IngressNightmare : La CVE Qui Peut Donner aux Attaquants l'Intégralité de Votre Cluster

On March 24, 2025, Wiz Research publicly disclosed five vulnerabilities in the Kubernetes Ingress-NGINX Controller collectively dubbed IngressNightmare. The most severe — CVE-2025-1974 (CVSS 9.8) — allows any unauthenticated attacker on the pod network to achieve remote code execution inside the ingress controller pod. Because ingress-nginx has cluster-wide read access to all Secrets by default, this single vulnerability frequently leads to a complete cluster takeover.

Le 24 mars 2025, Wiz Research a divulgué publiquement cinq vulnérabilités dans le contrôleur Kubernetes Ingress-NGINX, collectivement surnommées IngressNightmare. La plus grave — CVE-2025-1974 (CVSS 9.8) — permet à tout attaquant non authentifié sur le réseau de pods d'atteindre l'exécution de code à distance dans le pod du contrôleur d'entrée. Comme ingress-nginx dispose par défaut d'un accès en lecture à l'ensemble des Secrets du cluster, cette seule vulnérabilité mène fréquemment à une prise de contrôle complète du cluster.

CVE-2025-1974   CVSS 9.8 Critical  Unauthenticated RCE via admission webhook
CVE-2025-1097   CVSS 8.8 High      Configuration injection via annotation
CVE-2025-1098   CVSS 8.8 High      Configuration injection via mirror annotation
CVE-2025-24514  CVSS 8.8 High      Configuration injection via auth-url annotation
CVE-2025-24513  CVSS 5.3 Medium    Path traversal in auth-url handling

Affected: ingress-nginx < 1.12.1 or < 1.11.5
Fix:      Upgrade to ingress-nginx 1.12.1+ or 1.11.5+
Impact:   43% of cloud environments, 6,500+ clusters publicly exposed

The attack chain is elegant and devastating. An attacker with access to the pod network sends a crafted Ingress object containing malicious NGINX directives to the Validating Admission Controller (VAC) webhook, which runs with elevated privileges. The VAC processes the object without properly sanitizing embedded directives, leading to RCE in the controller pod. From there, the attacker reads all cluster Secrets and pivots to every workload the service accounts can reach.

La chaîne d'attaque est élégante et dévastatrice. Un attaquant avec accès au réseau de pods envoie un objet Ingress forgé contenant des directives NGINX malveillantes au webhook Validating Admission Controller (VAC), qui s'exécute avec des privilèges élevés. Le VAC traite l'objet sans assainir correctement les directives embarquées, conduisant à un RCE dans le pod du contrôleur. De là, l'attaquant lit tous les Secrets du cluster et pivote vers chaque workload accessible par les comptes de service.

runc Container Escape Trilogy: CVE-2025-31133, CVE-2025-52565, CVE-2025-52881

La Trilogie d'Évasions runc : CVE-2025-31133, CVE-2025-52565, CVE-2025-52881

On November 5, 2025, three container escape vulnerabilities were disclosed in runc — the OCI container runtime used by Docker, containerd, and every Kubernetes node. Discovered by a researcher at SUSE and disclosed through CNCF, these vulnerabilities exploit race conditions and symlink manipulation during container creation to break out of container isolation entirely.

Le 5 novembre 2025, trois vulnérabilités d'évasion de containers ont été divulguées dans runc — le runtime OCI utilisé par Docker, containerd et chaque nœud Kubernetes. Découvertes par un chercheur de SUSE et divulguées via le CNCF, ces vulnérabilités exploitent des conditions de course et des manipulations de liens symboliques lors de la création des containers pour sortir entièrement de l'isolation des containers.

CVE-2025-31133  maskedPaths bypass via /dev/null symlink substitution
                → Attacker redirects sysctl writes to /proc/sysrq-trigger
                → Can crash host or escape container

CVE-2025-52565  /dev/console bind mount race condition
                → Attacker manipulates mount target before security protections apply
                → Mounts arbitrary host paths inside container

CVE-2025-52881  procfs redirect bypassing LSM protections (AppArmor / SELinux)
                → Write to /proc/sys/kernel/core_pattern → container escape

Affected: runc < 1.2.8, < 1.3.3, < 1.4.0-rc.3
Fix:      Upgrade runc to 1.2.8+ / 1.3.3+ / 1.4.0-rc.3+
Mitigation: Enable user namespaces — blocks the most serious aspects of all three

The practical severity of these vulnerabilities depends on your threat model. An attacker needs to run a malicious container on your cluster — which is the starting condition for many supply chain attacks, including the TeamPCP campaign that compromised LiteLLM and Trivy in March 2026. If a compromised dependency is deployed into your cluster, runc CVEs are the next step in the kill chain.

La gravité pratique de ces vulnérabilités dépend de votre modèle de menace. Un attaquant doit pouvoir exécuter un container malveillant dans votre cluster — ce qui est précisément la condition de départ de nombreuses attaques supply chain, dont la campagne TeamPCP qui a compromis LiteLLM et Trivy en mars 2026. Si une dépendance compromise est déployée dans votre cluster, les CVE runc constituent l'étape suivante dans la kill chain.

RBAC Misconfigurations: The Silent Cluster-Admin Handout

Mauvaises Configurations RBAC : La Distribution Silencieuse des Droits cluster-admin

RBAC (Role-Based Access Control) is Kubernetes's primary authorization mechanism — and its most consistently misconfigured component. According to a 2026 analysis by Unit 42, 45% of Kubernetes environments have critical RBAC misconfigurations. The single most common finding: workloads shipped with cluster-admin ClusterRoleBindings, wildcard verbs ("*"), or unrestricted access to serviceaccounts/token — and then forgotten about.

RBAC (Role-Based Access Control) est le mécanisme d'autorisation principal de Kubernetes — et son composant le plus systématiquement mal configuré. Selon une analyse de 2026 par Unit 42, 45% des environnements Kubernetes ont des mauvaises configurations RBAC critiques. La constatation la plus fréquente : des workloads déployés avec des ClusterRoleBindings cluster-admin, des verbes génériques ("*"), ou un accès non restreint à serviceaccounts/token — puis oubliés.

# Pattern 1: wildcard verbs (grants everything)
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]      # Never do this in production

# Pattern 2: cluster-admin for application pods
roleRef:
  kind: ClusterRole
  name: cluster-admin   # A compromised pod now owns your cluster

# Pattern 3: serviceaccount token over-exposure
rules:
- apiGroups: [""]
  resources: ["serviceaccounts/token"]
  verbs: ["create"]    # Only needed by very specific controllers

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: app-reader
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch"]   # Only what the app actually needs

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: production
  name: app-reader-binding
subjects:
- kind: ServiceAccount
  name: my-app
  namespace: production
roleRef:
  kind: Role
  name: app-reader
  apiGroup: rbac.authorization.k8s.io

Service accounts outnumber human users by roughly four orders of magnitude in most Kubernetes environments and are 7.5× riskier in practice — they are always-on, often over-privileged, and rarely rotated. Every pod that mounts a service account token automatically gets a credential capable of authenticating to the Kubernetes API. The fix is to set automountServiceAccountToken: false on pods that don't need API access.

Les comptes de service dépassent en nombre les utilisateurs humains d'environ quatre ordres de grandeur dans la plupart des environnements Kubernetes et sont 7,5× plus risqués en pratique — ils sont toujours actifs, souvent sur-privilégiés et rarement renouvelés. Chaque pod qui monte un token de compte de service obtient automatiquement une credential capable de s'authentifier auprès de l'API Kubernetes. Le correctif consiste à définir automountServiceAccountToken: false sur les pods qui n'ont pas besoin d'accès à l'API.

Pod Security Admission: Enforce Container Hardening at the Namespace Level

Pod Security Admission : Enforcer le Durcissement des Containers au Niveau du Namespace

Pod Security Admission (PSA) has been stable since Kubernetes 1.25 and is the official replacement for the deprecated PodSecurityPolicy. It lets you enforce security profiles at the namespace level using three predefined standards: Privileged, Baseline, and Restricted. In 2026, the Restricted profile prevents most of the container escape paths exploited by the runc CVEs above.

Pod Security Admission (PSA) est stable depuis Kubernetes 1.25 et est le remplacement officiel de la PodSecurityPolicy dépréciée. Il vous permet d'appliquer des profils de sécurité au niveau du namespace en utilisant trois standards prédéfinis : Privileged, Baseline et Restricted. En 2026, le profil Restricted empêche la plupart des chemins d'évasion de containers exploités par les CVE runc mentionnées ci-dessus.

# Apply via namespace labels — no webhook or CRD required
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    # Enforce: block non-compliant pods
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest

    # Audit: log violations without blocking (for gradual rollout)
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: latest

    # Warn: show warnings in kubectl output
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: latest

┌─────────────┬──────────────────────────────────────────────────────┐
│  Privileged │ No restrictions. Use ONLY for infrastructure pods.   │
│             │ Never for application workloads.                     │
├─────────────┼──────────────────────────────────────────────────────┤
│  Baseline   │ Prevents known privilege escalations.               │
│             │ Disables: hostPID, hostIPC, hostNetwork,            │
│             │ privileged containers, most hostPath mounts.         │
│             │ Good default for application namespaces.             │
├─────────────┼──────────────────────────────────────────────────────┤
│  Restricted │ Maximum hardening. Requires:                         │
│             │ - runAsNonRoot: true                                 │
│             │ - allowPrivilegeEscalation: false                   │
│             │ - seccompProfile: RuntimeDefault or Localhost        │
│             │ - capabilities drop ALL                              │
│             │ Blocks most container escape paths.                  │
└─────────────┴──────────────────────────────────────────────────────┘

Start with Baseline enforcement and Restricted in audit/warn mode. This gives you visibility into non-compliant workloads without breaking production. Gradually tighten namespaces toward Restricted as your team adapts their Dockerfiles and Helm charts.

Commencez par l'enforcement Baseline et Restricted en mode audit/warn. Cela vous donne une visibilité sur les workloads non conformes sans casser la production. Resserrez progressivement les namespaces vers Restricted au fur et à mesure que votre équipe adapte ses Dockerfiles et charts Helm.

Other Critical Kubernetes CVEs in 2026

Autres CVE Kubernetes Critiques en 2026

Beyond the major vulnerability classes above, 2026 has already produced a steady stream of Kubernetes-adjacent CVEs that development teams need to track:

Au-delà des grandes classes de vulnérabilités mentionnées ci-dessus, 2026 a déjà produit un flux régulier de CVE adjacentes à Kubernetes que les équipes de développement doivent surveiller :

Kubernetes Security Hardening Checklist for 2026

Checklist de Durcissement Sécurité Kubernetes pour 2026

Based on the 2026 vulnerability landscape, here is a prioritized checklist for development teams running Kubernetes in production:

Sur la base du paysage des vulnérabilités 2026, voici une checklist priorisée pour les équipes de développement qui font tourner Kubernetes en production :

Frequently Asked Questions

Questions fréquentes