
Análisis técnico en profundidad de CVE-2025-1974 (IngressNightmare), una RCE crítica en el controlador de admisión de validación de ingress-nginx para Kubernetes, incluyendo causa raíz, cadena de explotación y guía de detección.
Este documento presenta la investigación de la vulnerabilidad CVE-2025-1974, que afecta al componente ingress-nginx (validating admission controller) para Kubernetes.
CVE-2025-1974 es una vulnerabilidad crítica (CVSS 3.1 9.8), que consiste en una ejecución remota de código (RCE) sin autenticación en el contexto del proceso ingress-nginx. Al realizar el ataque, un atacante con acceso a la red de pods (o la capacidad de enviar un AdmissionReview al validating webhook) puede lograr la ejecución de código arbitrario en el pod del controlador, lo que potencialmente conduce a la divulgación de Secrets y la toma del clúster.
Ingress-nginx es uno de los controladores Ingress más comunes en Kubernetes (las estimaciones muestran su uso en decenas de porcentaje de clústeres), por lo que el impacto práctico de la vulnerabilidad es muy alto. La descripción, el análisis técnico y las recomendaciones oficiales de corrección han sido publicados por Kubernetes, investigadores de Wiz y varios blogs de proveedores.
Analizar paso a paso CVE-2025-1974 y preparar los materiales necesarios para un write-up:
Esta investigación se lleva a cabo exclusivamente con fines educativos y éticos y está orientada a entornos de prueba/controlados.
Bajo ninguna circunstancia ejecute exploits/PoC contra clústeres ajenos o instancias de acceso público sin el permiso escrito del propietario. La publicación de un PoC completamente funcional y «armamentizado» en abierto aumenta enormemente el riesgo de abuso; en la parte pública es mejor presentar un safe-PoC y la metodología. (Los avisos oficiales y los proveedores también enfatizan la precaución al difundir exploits).
cpe:2.3:a:kubernetes:ingress-nginx_controller:<version> — versiones vulnerables de ingress-nginx (en los avisos se indican versiones concretas; actualice los valores en la publicación final).Condiciones de configuración en las que la vulnerabilidad es relevante:
Resumen breve.
La vulnerabilidad se encontró en el componente Validating Admission Controller del controlador Ingress-NGINX y está relacionada con la forma en que este componente genera y verifica la configuración temporal de NGINX basada en los Ingress / AdmissionReview entrantes. Durante el procesamiento, el controlador genera nginx.conf y ejecuta una verificación de configuración (nginx -t). Debido a una sanitización insuficiente de los campos de Ingress/AdmissionReview, un atacante puede insertar fragmentos especialmente preparados que se incorporan al archivo de configuración generado y, como resultado, provocan la ejecución de comandos dentro del proceso del controlador, es decir, una ejecución remota de código (RCE) en el pod de ingress-nginx.
AdmissionReview/Ingress entrantes, aceptados por el validating webhook del controlador, se convierten en datos de origen para la generación de la configuración de NGINX (incluyendo campos de anotaciones, configuraciones de backend, etc.).Ingress malicioso o un AdmissionReview directo pueden inyectar cadenas controladas en las plantillas/fragmentos de configuración. Al verificar/cargar dicho nginx.conf, el proceso de verificación (nginx -t) y las operaciones posteriores con el archivo de configuración pueden provocar la ejecución de código arbitrario, la escritura/ejecución de archivos o la ejecución de comandos en el contexto del controlador.AdmissionReview al validating webhook (acceso desde la red de pods o acceso de red directo); ausencia de medidas compensatorias como NetworkPolicy, restricciones RBAC o autenticación adicional del webhook. En algunos escenarios, la elusión de permisos de Create/Update es posible enviando un AdmissionReview manipulado directamente al webhook.
La explotación exitosa otorga ejecución de código en el contenedor ingress-nginx, lo que generalmente permite:
ingress-nginx-controller-admission y al servicio ingress-nginx-controller desde fuentes no estándar (en los informes, desde contenedores como alpine), algo que no debería ocurrir en funcionamiento normal.nginx -t y reinicios repentinos del controlador, así como operaciones inesperadas de escritura de archivos por parte del proceso ingress-nginx.Ingress-NGINX es uno de los controladores Ingress más utilizados en Kubernetes (ampliamente empleado para organizar el acceso externo a los servicios). El controlador actúa como un proxy inverso: recibe tráfico externo y lo redirige a los Services/Pods correspondientes según un conjunto de reglas Ingress. El proyecto Ingress-NGINX goza de gran popularidad y tiene una cuota de instalación significativa en clústeres accesibles desde Internet.
Ingress-NGINX aparece en la documentación de Kubernetes como ejemplo de referencia de un controlador Ingress. Según las estimaciones, una parte significativa de los clústeres abiertos lo utilizan; algunos estudios indican que alrededor del 41% de los clústeres públicos utilizan Ingress-NGINX. Es precisamente por su amplia adopción y su papel central en el enrutamiento de tráfico que las vulnerabilidades en este componente tienen un alto impacto práctico.
validate.nginx.ingress.kubernetes.io). Esto facilita su invocación desde dentro del clúster.Ingress / AdmissionReview especialmente manipulado, donde ciertos campos contienen cadenas maliciosas que no han pasado el filtrado adecuado.nginx.conf basado en estos datos de entrada y ejecuta nginx -t / otras operaciones de verificación.Este tipo de vulnerabilidades son especialmente peligrosas en combinación con otros defectos: un pod comprometido (o SSRF en una aplicación pública) + un validating webhook expuesto proporcionan una alta probabilidad de compromiso total. Por lo tanto, el análisis de incidentes debe considerar la cadena de dependencias y los vectores potenciales, no solo la versión de ingress-nginx.