Vulnerabilidad crítica en un componente de Kubernetes

Resumen del CVE-2025-1974

Se trata de un grave fallo de seguridad en Kubernetes. En particular, el problema está en el componente llamado Ingress NGINX Controller, que actúa como “puerta de entrada” para el tráfico web hacia las aplicaciones dentro de Kubernetes. El CVE-2025-1974 permite que un atacante tome el control de ese componente sin necesidad de iniciar sesión ni tener credenciales.

Técnicamente, el atacante puede enviar una instrucción especial al controlador de ingress que engaña al sistema y le hace correr código malicioso. Pero en pocas palabras, esta vulnerabilidad abre la posibilidad de que un desconocido ejecute código dentro del componente que dirige el tráfico del clúster de Kubernetes. 

El CVE-2025-1974 es una vulnerabilidad crítica de ejecución remota de código (RCE) descubierta en Kubernetes, específicamente en el componente Ingress NGINX Controller (controlador de ingress basado en Nginx)​. El fallo aparece en el webhook de admisión (Validating Admission Controller) que utiliza ingress-nginx para validar la configuración de ingress. El problema ha sido catalogado bajo la vulnerabilidad CWE-653 (“Improper Isolation or Compartmentalization” – aislamiento o compartimentación inadecuada)​, ya que el controlador no aísla correctamente la configuración suministrada por usuarios potencialmente maliciosos.

En resumen, la vulnerabilidad permite inyectar configuraciones arbitrarias de Nginx en el proceso de validación de ingress. Esto deriva en la ejecución de comandos o código arbitrario dentro del pod del Ingress Controller, comprometiendo ese componente por completo​. Dado que el Ingress Controller típicamente corre con privilegios elevados en el clúster, la explotación exitosa conlleva un acceso no autorizado a todos los secretos del clúster y una potencial toma de control total del clúster de Kubernetes​. Importante: aunque fue identificada junto a otras cuatro vulnerabilidades conocidas colectivamente como “IngressNightmare”​, CVE-2025-1974 es la más grave, ya que permite explotar las demás sin necesidad de permisos para crear objetos Ingress, ampliando enormemente el alcance del ataque​.

Mitigaciones, parches y recomendaciones

La solución recomendada es actualizar inmediatamente el ingress-nginx a una versión fija. Los mantenedores de Kubernetes han lanzado parches en las versiones v1.11.5 y v1.12.1 del controlador Ingress NGINX​. Actualizar a estas versiones (o superiores) elimina la vulnerabilidad corrigiendo el manejo de la configuración de Nginx. En los repositorios oficiales se proporcionan instrucciones de actualización; por ejemplo, si se usa Helm, bastaría con actualizar la versión del chart a la release parcheada, o si se desplegó manualmente, aplicar los manifest actualizados del controlador​.

En caso de no poder aplicar el parche de forma inmediata, se deben implementar mitigaciones temporales para reducir el riesgo mientras se planea la actualización.

• Deshabilitar el Validating Admission Controller de ingress-nginx: esto evita la vía de explotación a costa de perder las validaciones de conveniencia. Se puede lograr de dos formas:
  • Si ingress-nginx se instaló mediante Helm: volverlo a implementar con el valor controller.admissionWebhooks.enabled=false​.
  • Si la instalación es manual (YAML manifest): eliminar el recurso ValidatingWebhookConfiguration llamado ingress-nginx-admission y eliminar el parámetro –validating-webhook del despliegue del controlador​.

Estos pasos desactivan el webhook vulnerable. Importante: una vez que se actualice a una versión fija, se recomienda volver a habilitar el webhook de validación, ya que provee verificaciones útiles para detectar configuraciones incorrectas de Ingress antes de aplicarlas.

• Restringir el acceso de red al webhook de admisión: asegurarse de que solo el API Server de Kubernetes pueda comunicarse con el servicio de admission controller. Esto típicamente implica aplicar políticas de red estrictas donde resida ingress-nginx, bloqueando tráfico entrante desde cualquier pod que no sea el API Server​. En condiciones normales, el API Server es el único que debería invocar el webhook, por lo que limitar la conectividad a nivel de red mitiga ataques desde dentro del clúster. Asimismo, no se debe exponer el servicio de admisión al exterior (por ejemplo, evitando configuraciones que publiquen el puerto del webhook fuera del clúster)​.
• Monitoreo y detección: aunque hasta el momento de la divulgación no se conocen indicadores de compromiso confirmados (IoC) ni explotación activa​, se recomienda monitorear los pods de ingress-nginx en busca de comportamientos anómalos. Por ejemplo, Sysdig sugirió vigilar la carga de bibliotecas compartidas inusuales desde rutas temporales dentro del contenedor Nginx​. Herramientas como Falco pueden detectar si el proceso nginx carga archivos sospechosos. Si se sospecha de un compromiso, debe rotar de inmediato todos los secretos accesibles por el controlador y revisar la integridad del clúster.

Vector de ataque y mecanismo de explotación

El vector principal de ataque es la red interna del clúster. Un atacante no autenticado que tenga alcance a la red interna de Kubernetes puede enviar una solicitud maliciosa al webhook de validación de ingress-nginx​. No se requieren credenciales ni rol de administrador en el clúster para explotar el fallo, únicamente la capacidad de comunicarse con el servicio de admisión del controlador Ingress​. Bajo condiciones normales, un actor malicioso tendría que poseer permisos para crear un objeto Ingress en Kubernetes (lo cual es una acción privilegiada) a fin de abusar de las vulnerabilidades de inyección de configuración. Sin embargo, el CVE-2025-1974 elimina ese requisito. Cualquier entidad con acceso de red al Admission Controller puede explotar el fallo al enviar directamente un objeto Ingress especialmente diseñado, explotando la funcionalidad de validación antes de que el objeto persista.

La explotación consiste en inyectar directivas Nginx arbitrarias en la configuración generada durante la validación. El controlador vulnerable no sanea apropiadamente ciertos campos (por ejemplo, el UID del Ingress u otras anotaciones) y los inserta tal cual en el archivo de configuración de Nginx para su validación​. Ingress-nginx procede a ejecutar nginx -t (modo prueba) para verificar la validez de la configuración generada. Mediante entradas manipuladas, los investigadores descubrieron que es posible introducir directivas peligrosas en ese archivo de configuración temporal. En particular, aprovecharon la directiva ssl_engine (parte del módulo de OpenSSL de Nginx) para cargar una biblioteca compartida maliciosa en memoria durante la fase de prueba de configuración.

El ataque completo requiere varios pasos: 

1. El atacante logra que Nginx acepte la carga maliciosa (payload) de una biblioteca compartida en el sistema de archivos del pod vulnerable. Para ello, abusa del mecanismo de client body buffering de Nginx enviando un cuerpo de petición HTTP lo suficientemente grande (>8 KB), provocando que Nginx lo guarde temporalmente en disco​. 
2. Aunque Nginx intenta borrar inmediatamente el archivo temporal, existe una condición de carrera donde el archivo permanece accesible a través de un descriptor abierto​. 
3. Acto seguido, al validar la configuración maliciosa, la directiva ssl_engine apunta a esa biblioteca temporal y fuerza a Nginx a cargarla, ejecutando el código arbitrario incluido en la librería​. De esta manera, el atacante obtiene ejecución de código dentro del pod del Ingress Controller sin autenticación.

Cabe destacar que la superficie de ataque se limita normalmente a la red interna del clúster; sin embargo, se descubrió que miles de clústeres tienen expuesto el webhook de admisión a Internet​, lo que podría permitir la explotación remota desde cualquier lugar. Para contextos donde el webhook no es accesible externamente, el atacante suele necesitar primero comprometer algún activo dentro del clúster (por ejemplo, mediante otro exploit o vulnerabilidad de aplicación) o usar técnicas de SSRF desde aplicaciones internas para luego apuntar al Admission Controller.

Más información:

• https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/
• https://nvd.nist.gov/vuln/detail/CVE-2025-1974
• https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities
• https://projectdiscovery.io/blog/ingressnightmare-unauth-rce-in-ingress-nginx
• https://artifacthub.io/packages/helm/ingress-nginx/ingress-nginx

La entrada Vulnerabilidad crítica en un componente de Kubernetes se publicó primero en Una Al Día.