ingress-nginx: CVE-2026-3288 y 4342, inyección y fin de vida

Si tu cluster de Kubernetes expone servicios con ingress-nginx, hay dos vulnerabilidades nuevas que conviene mirar hoy y no el lunes: CVE-2026-3288 y CVE-2026-4342, ambas de inyección de configuración con CVSS 8.8. Las dos permiten meter directivas arbitrarias de nginx desde un objeto Ingress y terminar ejecutando código en el controlador y leyendo los Secrets a los que tiene acceso. Lo que las vuelve especialmente incómodas es el timing: aparecen en las últimas semanas de vida del proyecto, que acaba de declararse End-of-Life.

CVE-2026-3288 y CVE-2026-4342 son dos vulnerabilidades de inyección de configuración en ingress-nginx, el controlador de Ingress más usado del ecosistema Kubernetes, mantenido por el proyecto Kubernetes. Ambas tienen CVSS 8.8 (alto): permiten que quien pueda crear o modificar recursos Ingress inyecte directivas de nginx, logre ejecución de código en el contexto del controlador y exfiltre Secrets accesibles para él. La 3288 abusa de la anotación rewrite-target; la 4342, de una combinación de anotaciones.

¿Qué hacen exactamente CVE-2026-3288 y CVE-2026-4342?

Ambas convierten un recurso Ingress —que en teoría solo describe reglas de ruteo— en un vector para inyectar configuración de nginx. El resultado, según el aviso oficial de seguridad de Kubernetes para la 4342, es directo: "puede llevar a ejecución de código arbitrario en el contexto del controlador ingress-nginx y a la divulgación de Secrets accesibles para el controlador". La misma frase aplica a la 3288. Se diferencian en el mecanismo:

• CVE-2026-3288 explota la anotación rewrite-target. Metiendo una comilla doble en el campo path del Ingress, el atacante cierra antes de tiempo el string de nginx e inyecta directivas propias. Publicada y parcheada el 9 de marzo de 2026.
• CVE-2026-4342 usa una combinación de anotaciones y comentarios. El aviso la describe como "comment-based nginx configuration injection": ciertas anotaciones combinadas escapan el comentario y cuelan configuración. Publicada el 19 de marzo de 2026, reportada por wooseokdotkim.
• Las dos son primas de CVE-2026-24512. Ese path injection previo (que ya cubrimos en el blog) se arregló un mes antes en buildLocation(); la 3288 es, en esencia, la misma clase de bug en otra función que el primer parche no había tapado.

¿Cómo funciona la inyección por el campo path?

El núcleo del problema es que ingress-nginx interpola datos controlados por el usuario dentro del archivo de configuración de nginx sin escaparlos. El análisis técnico de Sysdig sobre CVE-2026-3288 lo resume así: "la variable path viene directamente del campo spec.rules.http.paths.path del Ingress y se interpola dentro de un string de nginx entre comillas dobles sin ningún escape".

La mecánica, paso a paso, es la de un SQL injection clásico pero contra un archivo de config:

1. El atacante define un Ingress con un path malicioso. En vez de una ruta normal, incluye una comilla doble para romper la sintaxis esperada.
2. El controlador genera el nginx.conf con esa comilla adentro. Como no hay sanitización, la comilla cierra el valor original y lo que sigue se lee como directivas de nginx.
3. nginx recarga la config inyectada. A partir de ahí el atacante dispone de directivas como return, variables como $http_authorization y del bloque location.

Con eso, según el mismo análisis, se abren varios abusos concretos: secuestrar respuestas con contenido propio, redirigir usuarios a sitios de phishing, robar credenciales leyendo el header Authorization, filtrar IPs internas de pods o directamente tirar el servicio con una config inválida.

¿Quién puede explotar esto y qué se lleva?

No es una vuln anónima desde internet: el atacante necesita estar autenticado contra la API de Kubernetes y tener permiso para crear o modificar recursos Ingress en algún namespace. Eso baja el riesgo frente a un RCE preauth, pero no lo vuelve teórico:

• El controlador suele ser un objetivo jugoso. ingress-nginx corre con acceso a Secrets del cluster; comprometerlo puede significar leer certificados TLS y credenciales de varios namespaces.
• El permiso "crear Ingress" se reparte más de lo que parece. Muchos equipos de plataforma delegan la gestión de Ingress a desarrolladores por namespace, o lo exponen vía GitOps y pipelines. Cualquiera de esos caminos alcanza.
• Es un escalón lateral perfecto. Un pod o cuenta de servicio ya comprometido con permisos sobre Ingress se transforma, con esto, en control del data plane L7.

¿Por qué duele más ahora: ingress-nginx llegó a fin de vida?

Porque estos son, básicamente, de los últimos parches que vas a ver. El 24 de marzo de 2026 kubernetes/ingress-nginx alcanzó oficialmente su End-of-Life y el repositorio quedó en solo lectura: no hay más features, no hay más bug fixes y —lo importante acá— no habrá más parches de CVE. La declaración del Steering Committee y del Security Response Committee del 29 de enero ya avisaba que el motivo central era, justamente, la carga de seguridad del proyecto.

El alcance no es menor: se estima que ingress-nginx está presente en cerca del 50% de los entornos cloud-native. Y hay un costo de compliance concreto: correr software EOL en el path de datos L7 dispara hallazgos automáticos en auditorías de SOC 2, PCI-DSS, ISO 27001 y HIPAA. Ojo con una distinción que se malinterpreta: lo que se retira es el controlador ingress-nginx, no la API Ingress de Kubernetes, que sigue siendo parte del core.

¿Qué podés hacer hoy?

Dos frentes: parchear ya para tapar estos CVE, y arrancar el plan de salida porque no van a venir más arreglos. En orden de urgencia:

• Actualizá a las versiones corregidas. Para la 4342, subí a v1.13.9, v1.14.5 o v1.15.1 (o superior de cada línea); esas ya traen también el fix de la 3288 (v1.13.8 / v1.14.4 / v1.15.0). Seguí la guía oficial de upgrade.
• Auditá tus Ingress existentes por comillas sospechosas. Un one-liner de Sysdig: kubectl get ingress -A -o json | jq '.items[].spec.rules[].http.paths[].path' | grep '["\;\#]'. Un path legítimo nunca lleva esos caracteres.
• Cerrá el permiso de crear Ingress por RBAC. Revisá quién puede create/update sobre ingresses y recortá a lo mínimo. Es el requisito previo de ambos ataques.
• Dejá el admission webhook prendido. Viene por defecto en los charts de Helm y valida los recursos antes de aplicarlos; no lo desactives "para que ande".
• Planificá la migración a Gateway API. El 20 de marzo SIG-Network liberó ingress2gateway 1.0, una herramienta estable que traduce 30+ anotaciones de Ingress a Gateway API. Es el camino recomendado a futuro; si querés arrancar por lo conceptual, tenemos una nota sobre enrutar tráfico con Gateway API en Kubernetes como lectura complementaria.

Preguntas frecuentes

¿Estoy afectado si no uso la anotación rewrite-target?

Podés estarlo igual. CVE-2026-3288 pasa por rewrite-target, pero CVE-2026-4342 usa una combinación de anotaciones distinta. Mientras corras una versión de ingress-nginx anterior a v1.13.9 / v1.14.5 / v1.15.1, estás expuesto a al menos una de las dos.

¿Se explota desde internet sin autenticación?

No. Ambos CVE requieren estar autenticado en la API de Kubernetes y tener permiso para crear o modificar recursos Ingress. No es un RCE anónimo desde afuera, sino un vector de escalada para quien ya tiene algún acceso interno.

¿Qué versión me deja cubierto por los dos CVE a la vez?

Subí como mínimo a v1.13.9, v1.14.5 o v1.15.1 según tu línea. Esas incluyen el fix de la 4342 y, por acumulación, también el de la 3288 (que se había liberado en v1.13.8 / v1.14.4 / v1.15.0).

¿Tiene sentido seguir con ingress-nginx después de parchear?

Como solución temporal, sí; como estrategia, no. Desde el 24 de marzo de 2026 el proyecto está EOL y no recibirá más parches de seguridad. Parchear estos CVE te compra tiempo, pero el plan real es migrar a Gateway API con ingress2gateway.

¿Se retira también la API Ingress de Kubernetes?

No. Lo que llega a fin de vida es el controlador ingress-nginx, no el recurso Ingress. La API Ingress sigue siendo parte del core de Kubernetes; lo que cambia es qué controlador la implementa.

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting