Se han detectado cuatro vulnerabilidades cr\u00edticas en el controlador de ingreso ingress-nginx del proyecto Kubernetes en desarrollo, que permiten ejecutar c\u00f3digo en los servidores de sistemas en la nube que utilizan la plataforma Kubernetes y obtener acceso completo y privilegiado al cl\u00faster de Kubernetes. Estas vulnerabilidades tienen un nivel de gravedad cr\u00edtico (9.8 de 10). Los investigadores que identificaron los problemas han asignado el nombre en c\u00f3digo IngressNightmare a estas vulnerabilidades y han se\u00f1alado que afectan aproximadamente al 43% de los entornos en la nube. Las vulnerabilidades se han corregido en las versiones ingress-nginx 1.11.5 y 1.12.1. <\/p>\n
El controlador de ingreso act\u00faa como una puerta de enlace y se utiliza en Kubernetes para organizar el acceso desde la red externa a los servicios dentro del cl\u00faster. El controlador ingress-nginx es el m\u00e1s popular y utiliza servidor<\/a> NGINX para redirigir las solicitudes al cl\u00faster, enrutando las peticiones externas y equilibrando la carga. El proyecto Kubernetes proporciona controladores de ingreso b\u00e1sicos para AWS, GCE y nginx, este \u00faltimo no est\u00e1 relacionado con el controlador kubernetes-ingress, cuya gesti\u00f3n est\u00e1 a cargo de la empresa F5\/NGINX (las vulnerabilidades mencionadas no afectan a los proyectos desarrollados por los desarrolladores de NGINX; la menci\u00f3n de nginx en el nombre ingress-nginx est\u00e1 relacionada \u00fanicamente con el uso de nginx como proxy). <\/p>\n Las vulnerabilidades permiten a un atacante no autenticado ejecutar su c\u00f3digo en el contexto del controlador ingress-nginx, teniendo la posibilidad de enviar una solicitud al manejador web Admission. Durante el escaneo de la red se han identificado m\u00e1s de 6500 cl\u00fasters de Kubernetes vulnerables que utilizan controladores p\u00fablicos con un manejador de Admission expuesto a solicitudes externas. <\/p>\n En la configuraci\u00f3n predeterminada, el c\u00f3digo ejecutado por un atacante puede acceder a la configuraci\u00f3n del objeto Ingress, en la cual, entre otras cosas, se almacenan las credenciales para acceder a los servidores de Kubernetes, lo que permite obtener acceso privilegiado a todo el cl\u00faster. Para eludir esta vulnerabilidad, se recomienda desactivar la funci\u00f3n de 'Validating Admission Controller' en ingress-nginx. <\/p>\n El controlador Admission se ejecuta en un pod separado y realiza la verificaci\u00f3n de los objetos ingress entrantes antes de su implementaci\u00f3n. Por defecto, el manejador web Admission acepta solicitudes sin autenticaci\u00f3n desde la red p\u00fablica. Al realizar la verificaci\u00f3n, el controlador Admission crea una configuraci\u00f3n para el servidor http nginx basada en el contenido del objeto ingress recibido y verifica su validez. <\/p>\n Las vulnerabilidades detectadas permiten la inyecci\u00f3n de configuraciones personalizadas en nginx a trav\u00e9s del env\u00edo de un objeto ingress espec\u00edficamente formado directamente al controlador de Admission. Los investigadores han descubierto que algunas propiedades de las solicitudes de verificaci\u00f3n, establecidas en el campo '.request.object.annotations', se insertan directamente en la configuraci\u00f3n de nginx. La configuraci\u00f3n generada no se aplica, sino que solo se prueba ejecutando el archivo ejecutable 'nginx' con la opci\u00f3n '-t'. <\/p>\n En particular, la inyecci\u00f3n de datos externos en la configuraci\u00f3n se realiza para los par\u00e1metros 'mirror-target', 'mirror-host' (CVE-2025-1098), 'auth-tls-match-cn' (CVE-2025-1097) y 'auth-url' (CVE-2025-24514). Por ejemplo, en la l\u00ednea de configuraci\u00f3n 'set $target {{ $externalAuth.URL }};', en lugar de '{{ $externalAuth.URL }}', se inserta la URL especificada en el par\u00e1metro 'auth-url'. No se verifica la validez de la URL. Como resultado, un atacante podr\u00eda pasar un valor como URL 'http:\/\/example.com\/#;\nconfiguraci\u00f3n' e inyectar su propia configuraci\u00f3n en el archivo de configuraci\u00f3n. <\/p>\n Para ejecutar c\u00f3digo arbitrario durante la verificaci\u00f3n de la configuraci\u00f3n con el comando 'nginx -t', los investigadores aprovecharon el hecho de que, adem\u00e1s de verificar la sintaxis, nginx carga bibliotecas de m\u00f3dulos y abre archivos mencionados en la configuraci\u00f3n para evaluar su disponibilidad. Entre otras cosas, al procesar la directiva ssl_engine, se carga la biblioteca compartida especificada en la directiva para SSL<\/a>-el motor. <\/p>\n Para cargar su biblioteca en el servidor de Kubernetes, los investigadores aprovecharon (CVE-2025-1974) el hecho de que al procesar solicitudes grandes, nginx guarda el cuerpo de la solicitud en un archivo temporal que se elimina inmediatamente, pero en el sistema de archivos \u00ab\/proc\u00bb queda un descriptor de archivo abierto para este archivo. De esta manera, se pueden enviar simult\u00e1neamente solicitudes para guardar el archivo temporal e iniciar una verificaci\u00f3n de configuraci\u00f3n, en la que en la directiva \u00abssl_engine\u00bb se indica la ruta al descriptor en el sistema de archivos \u00ab\/proc\u00bb. <\/p>\n Para que el descriptor de archivo permanezca disponible durante un per\u00edodo prolongado, se puede especificar un valor de \u00abContent-Length\u00bb en la solicitud que sea deliberadamente mayor que los datos transmitidos (el servidor esperar\u00e1 la recepci\u00f3n de los datos restantes). Una complejidad adicional es la necesidad de adivinar el PID del proceso y el n\u00famero del descriptor de archivo asociado con la biblioteca compartida cargada, pero dado que en el contenedor normalmente se utiliza un n\u00famero m\u00ednimo de procesos en ejecuci\u00f3n, los valores necesarios se adivinan mediante prueba y error en varios intentos. En caso de \u00e9xito y carga de la biblioteca compartida sustituida, el atacante puede acceder a los par\u00e1metros almacenados dentro del entorno pod, suficientes para controlar todo el cl\u00faster.