Kyverno CVE-2026-22039 expone datos entre namespaces de Kubernetes

Qué inició el debate

Acabo de ver esta desagradable CVE de Kyverno, un ejemplo perfecto de por qué desconfío de los admission controllers con permisos RBAC omnipotentes.

La vulnerabilidad CVE-2026-22039 permite a cualquier usuario con permisos sobre políticas de namespace exfiltrar datos de CUALQUIER namespace abusando de la sustitución de variables en llamadas a la API. El atacante crea una política en su propio namespace restringido, la activa mediante anotaciones que apuntan a recursos de kube-system y listo: la cuenta de servicio cluster-admin de Kyverno hace el trabajo sucio en su lugar.

Se corrigió en 1.16.3 y 1.15.3, pero esto evidencia cómo estas herramientas de seguridad pueden transformarse en el vector de ataque más peligroso.

Qué destacó en los comentarios

Punto de debate 1

Esto en realidad no parece ni mejor ni peor que cualquiera del millón de CVE relacionadas con anotaciones de snippets que han afectado a ingress-nginx en los últimos años.

Punto de debate 2

A ver... ¿sí? Siempre hay que ser muy consciente del poder que ostenta una aplicación. La documentación de Kyverno está repleta de advertencias sobre cómo una mala gestión de la instalación puede bloquear tu clúster, restringir componentes clave para los usuarios, etc. En mi opinión, Kyverno es una herramienta fantástica.

Punto de debate 3

Para ser justos, este tipo de problemas ha existido siempre en cualquier tecnología que requiera privilegios elevados. Al final del día, sin embargo, el volumen de basura y fallos que Kyverno probablemente ha detectado y evitado supera con creces esta CVE en particular. Aunque no he leído la CVE en profundidad, la descripción que aportas parece dar a entender que el atacante necesitaría tener acceso a un namespace desde el principio. Eso reduce MUCHO la superficie de ataque y la probabilidad de explotación. Como ocurre con tantas cosas, todo se reduce al modelo de amenazas. No digo que deban permitirse sin control cuentas de servicio y admission controllers omnipotentes, y sus desarrolladores deberían esforzarse por limitar los permisos exigidos (igual que cualquiera que siga el principio de mínimo privilegio), pero entender qué implica esto para tus clústeres es fundamental.

Punto de debate 4

Participé en tareas de desarrollo en Kyverno hace un par de años y el código fuente era un absoluto desastre.

Punto de debate 5

Los namespaces no son barreras de seguridad y nunca lo han sido. Herramientas como vCluster "aíslan" clústeres virtuales independientes mediante namespaces, pero necesitas habilitar NetworkPolicies de forma explícita para lograr un aislamiento de red este-oeste auténtico. Además, en el modelo predeterminado de nodos de trabajo (compartido o en el host), persisten todas las preocupaciones clásicas sobre escapes de contenedores, vecinos ruidosos y movimientos laterales, por lo que PSA se vuelve aún más determinante. La situación mejora y se simplifica con soluciones como vCluster pero, aun así, lograr multitenencia exclusivamente mediante Kubernetes siempre ha sido un reto complejo para los equipos de plataforma y lo seguirá siendo. Como sucede con otros asuntos de seguridad, la gente siempre recordará que Kubernetes no se diseñó con muchas de estas cuestiones en mente, y ha hecho falta la implicación de los SIG, la comunidad de código abierto y diversas organizaciones para impulsar la innovación en este ámbito.

Resumen del hilo

• Subreddit original: r/kubernetes
• Autor original: u/RemmeM89
• Puntuación en Reddit: 79
• Número de comentarios: 24
• Hilo original: https://www.reddit.com/r/kubernetes/comments/1r44yxo/cve202622039_how_an_admission_controller/