CVE-2026-24512: RCE en ingress-nginx de Kubernetes

Hay una clase de vulnerabilidad que asusta más que un RCE remoto anónimo: la que convierte un permiso que creías inofensivo en control total del cluster. Eso es exactamente CVE-2026-24512 en ingress-nginx, el controlador de Ingress más usado de Kubernetes. El truco es viejo pero letal: el campo path de un objeto Ingress —texto que cualquier equipo de dev escribe todos los días— termina inyectado dentro de la configuración de nginx sin sanear. Y de ahí a ejecutar código dentro del controlador hay un solo paso.

CVE-2026-24512 es una vulnerabilidad de inyección de configuración en ingress-nginx, el controlador de Ingress de Kubernetes mantenido por la comunidad. El campo rules.http.paths.path de un recurso Ingress no se saneaba antes de escribirse en la config de nginx, así que un usuario con permiso RBAC para crear o modificar Ingress puede inyectar directivas y lograr ejecución de código dentro del pod del controlador. Tiene CVSS v3.1 de 8.8 (alto) y se corrigió en febrero de 2026.

¿Cómo un campo de texto se convierte en ejecución de código?

CVE-2026-24512: un path de Ingress que da RCE en Kubernetes

Porque ingress-nginx toma lo que escribís en el campo path y lo interpola directamente dentro de un archivo nginx.conf, que es un formato con su propia sintaxis. Si metés los caracteres correctos —una comilla doble, una barra invertida— rompés el bloque location esperado y empezás a escribir tu propia configuración de nginx. Y nginx, con el módulo Lua que trae ingress-nginx, sabe ejecutar código.

El mecanismo concreto, según el aviso oficial de Kubernetes, está en la función buildLocation() del controlador, que no escapaba la entrada del usuario. La corrección introdujo una función sanitizeQuotedRegex() que escapa las comillas y las barras invertidas antes de escribirlas en la config. Un ejemplo simplificado de cómo se ve un path malicioso:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: inofensivo
spec:
  rules:
  - http:
      paths:
      - path: '/foo" { ... directivas nginx inyectadas ... } location "/'
        pathType: ImplementationSpecific
        backend: ...

La clave es pathType: ImplementationSpecific: es el único tipo de path que no valida el formato de la ruta, así que es el vector natural del ataque. Los tipos Prefix y Exact sí validan y no permiten estos caracteres.

¿Qué puede hacer un atacante con esto?

Ejecutar código dentro del pod del controlador ingress-nginx y, en una instalación por defecto, leer todos los Secrets del cluster. Ese es el verdadero problema: el controlador necesita acceso a los Secrets de TLS de todos los namespaces para servir HTTPS, así que su ServiceAccount típicamente puede leer secrets a nivel cluster. RCE ahí adentro no es "comprometí un pod", es "tengo las credenciales de todo".

El impacto documentado en el aviso y en el análisis de Sysdig incluye:

Ejecución de código arbitrario en el proceso del controlador ingress-nginx, con los privilegios de su ServiceAccount.
Robo de Secrets a nivel cluster. En la config por defecto el controlador ve todos los Secrets, lo que amplifica muchísimo el alcance.
Secuestro de respuestas HTTP inyectando directivas return para redirigir o falsear tráfico legítimo.
Robo de credenciales en tránsito usando variables de nginx como $http_authorization para capturar headers de autenticación de las requests que pasan.
Denegación de servicio generando una configuración inválida que hace que nginx deje de recargar.

¿Quién puede explotar CVE-2026-24512? El detalle del "usuario autenticado"

No es un anónimo desde internet: el atacante necesita permiso RBAC para crear o modificar objetos Ingress en algún namespace. Por eso el título habla de "usuario autenticado". El vector CVSS lo dice claro: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — PR:L significa privilegios bajos, no nulos.

Suena tranquilizador hasta que pensás en tu cluster real. En la mayoría de las organizaciones, crear un Ingress es un permiso rutinario: se lo das a cada equipo de desarrollo, a cada namespace de una app, a cada pipeline de CI/CD que despliega con Helm. Es justamente el permiso que uno reparte sin pensarlo dos veces. CVE-2026-24512 toma esa confianza —un tenant que solo debería poder exponer su propio servicio— y la convierte en escape hacia el resto del cluster. Es el clásico problema de multi-tenancy blando en Kubernetes: la frontera del namespace es más porosa de lo que parece.

¿Por qué esto sigue importando en agosto de 2026?

Porque el parche inicial estaba incompleto y porque ingress-nginx es omnipresente. La corrección de CVE-2026-24512 aplicó sanitizeQuotedRegex() a buildLocation() pero se olvidó de buildProxyPass(), dejando abierta la directiva rewrite. Eso derivó en un segundo CVE, CVE-2026-3288, corregido recién el 9 de marzo de 2026 en las versiones v1.13.8, v1.14.4 y v1.15.0. O sea: si parchaste apurado en febrero, quizás seguís expuesto por la vía del hermano gemelo.

Sumale que ingress-nginx es uno de los componentes más desplegados del ecosistema y que los clusters se parchean con notoria lentitud. No hay evidencia pública de explotación masiva en la naturaleza ni está en el catálogo KEV de CISA a la fecha, pero según la base de datos de vulnerabilidades de Wiz ya existe un exploit público. Con PoC dando vueltas y superficie de ataque gigante, "todavía nadie lo explotó a gran escala" no es un plan de seguridad.

El hallazgo se lo debemos a Maxime Escourbiac y Yassine Bengana, del CERT de Michelin, y la corrección a Steven Jin, Tabitha Sable y Marco Ebert del proyecto Kubernetes.

¿Qué versiones de ingress-nginx están afectadas y cuáles son seguras?

Cualquier versión anterior a v1.13.7 y v1.14.3 es vulnerable a CVE-2026-24512. Pero para cubrir también el CVE-2026-3288 que quedó del fix incompleto, el piso seguro es más alto. Esta es la foto:

CVE	Función afectada	Versiones que corrigen	Fecha
CVE-2026-24512	`buildLocation()`	v1.13.7 · v1.14.3	Febrero 2026
CVE-2026-3288	`buildProxyPass()`	v1.13.8 · v1.14.4 · v1.15.0	9 de marzo de 2026

Recomendación práctica: actualizá directamente a v1.14.4 (o v1.13.8 si estás en la rama 1.13, o v1.15.0). Así quedás cubierto de las dos vulnerabilidades de una sola vez, sin la ventana intermedia.

¿Qué podés hacer HOY para blindarte?

Actualizar es la solución definitiva, pero hay pasos de contención y verificación que aplicás en minutos. En orden de prioridad:

Actualizá el controlador a v1.14.4, v1.13.8 o v1.15.0 según tu rama. Es el único fix real.
Auditá tus Ingress existentes buscando caracteres sospechosos en los paths. Un one-liner sirve: kubectl get ingress -A -o json | jq '.items[].spec.rules[].http.paths[].path' y revisá si aparece alguna comilla doble donde no debería.
Restringí el RBAC de creación de Ingress al mínimo necesario. Si un pipeline no necesita crear Ingress arbitrarios, no le des el verbo create sobre ese recurso.
Bloqueá pathType: ImplementationSpecific con un admission controller de validación (por ejemplo con Kyverno o Gatekeeper) mientras no puedas actualizar. Es el workaround temporal que sugiere el propio proyecto.
Verificá que el admission webhook de ingress-nginx esté habilitado. Ayuda a rechazar configuraciones malformadas antes de que lleguen a nginx.

Si te interesa la parte de detección, el equipo de Sysdig publicó una regla de Falco que alerta cuando aparece una comilla doble en el campo path de un Ingress a través de los audit logs de Kubernetes. Es un buen complemento defensivo mientras coordinás la actualización.

Preguntas frecuentes

¿CVE-2026-24512 se puede explotar sin autenticación?

No. El atacante necesita credenciales válidas en la API de Kubernetes y permiso RBAC para crear o modificar recursos Ingress en algún namespace. El vector es PR:L (privilegios bajos, pero no nulos). El riesgo real está en lo común que es repartir ese permiso a equipos y pipelines.

¿Qué diferencia hay entre CVE-2026-24512 y CVE-2026-3288?

Son la misma clase de bug —inyección de config vía el campo path— pero en funciones distintas del controlador. CVE-2026-24512 estaba en buildLocation() y se corrigió en febrero; CVE-2026-3288 apareció porque ese primer parche no cubrió buildProxyPass(), y se corrigió el 9 de marzo de 2026.

¿Con qué versión quedo cubierto de ambas vulnerabilidades?

Con v1.14.4, v1.13.8 o v1.15.0. Esas versiones incluyen el sanitizeQuotedRegex() aplicado tanto a buildLocation() como a buildProxyPass(), así que resuelven el CVE-2026-24512 y su continuación de un solo salto.

¿Uso Ingress pero no ingress-nginx: me afecta?

No. Estas CVE son específicas del controlador ingress-nginx (el proyecto de la comunidad Kubernetes). Otros controladores de Ingress o implementaciones de Gateway API tienen su propio código y no comparten este bug. Aun así, la lección de saneo de entradas es universal: cualquier controlador que interpole texto del usuario en un archivo de configuración puede caer en algo parecido.

El aprendizaje que trasciende esta CVE

CVE-2026-24512 es un recordatorio de que en Kubernetes la superficie de ataque no son solo los binarios y los CVE remotos: son los permisos que repartís. Un Ingress es "solo enrutamiento" hasta que un campo de texto sin sanear lo convierte en ejecución de código. Vale la pena revisar el principio de mínimo privilegio en tu RBAC, aislar tenants con políticas de red y tratar a cada controlador con acceso amplio a Secrets como lo que es: un objetivo de alto valor. Si te interesa reforzar ese lado, temas como aislar microservicios con NetworkPolicy o gestionar Secrets sin filtrarlos en los manifiestos son buenas lecturas complementarias que ya cubrimos en el blog.

Fuentes y para profundizar: el aviso oficial del proyecto Kubernetes (issue #136678), el registro en NVD y el análisis técnico y de detección de Sysdig.