Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
CVE-2025-1974 — 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. | Kitploit
Herramientas/GitHubGitHub/iteride/cve-2025-1974
Seguridad de ContenedoresAnálisis de VulnerabilidadesExplotaciónSeguridad WebSeguridad en la NubePapers e InvestigaciónAprendizaje y Educación
GitHubiteride/cve-2025-1974

CVE-2025-1974

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.

Ver Repositorio
hace 11 mesesAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

CVE-2025-1974 — IngressNightmare (ingress-nginx)

Introducció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.


Objetivo del informe

Analizar paso a paso CVE-2025-1974 y preparar los materiales necesarios para un write-up:

  1. Recopilación y estructuración de materiales. Reunir avisos oficiales, write-ups de investigación y análisis de proveedores; destacar los detalles técnicos clave y las direcciones de PoC.
  2. Comprender la esencia de la vulnerabilidad y su impacto. Explicar la causa raíz, la cadena de ataque y las posibles consecuencias (RCE → divulgación de Secrets → toma del clúster).
  3. Determinar CPE y condiciones de configuración. Enumerar las versiones/paquetes y configuraciones de Kubernetes/ingress-nginx en las que la vulnerabilidad es relevante.
  4. Dar recomendaciones para pruebas seguras en laboratorio y minimización del riesgo durante la verificación masiva.

⚠️ Descargo de responsabilidad

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 y condiciones de configuración

  • 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).
  • Proveedores/distribuciones que incluyen el controlador vulnerable:
    • Distribuciones RKE2 / Rancher con ingress-nginx hasta las versiones de parche indicadas.
    • Versiones de Harvester que utilizan ingress-nginx vulnerable (el KB del proveedor contiene builds afectados concretos).
    • Clústeres personalizados donde ingress-nginx está instalado por separado (Helm chart/manifest): verificar versiones del chart/image.

Condiciones de configuración en las que la vulnerabilidad es relevante:

  1. Versión vulnerable de ingress-nginx (anterior a la versión/publicación del parche indicado en los avisos). Consulte los números de versión exactos en NVD y en los avisos de los proveedores.
  2. Validating admission webhook accesible desde fuera de la red de pods — si el webhook es accesible desde el exterior (por ejemplo, endpoint público, el proveedor expuso el servicio por error), el exploit puede ejecutarse de forma remota. Wiz y otros investigadores señalaron numerosos casos de exposición pública.
  3. Ausencia de NetworkPolicy / aislamiento de la red de pods: si un atacante puede enviar solicitudes desde cualquier pod a la red del clúster (pod comprometido), esto es suficiente para la explotación.
  4. Ausencia de validaciones/ACL adicionales antes del admission controller: los filtros adicionales/autenticación de ingreso-proxy pueden reducir el riesgo.
  5. Presencia en el contenedor ingress-nginx de una serviceAccount con amplios permisos y acceso a Secrets — por defecto, el controlador a menudo monta una serviceAccount con amplios permisos; esto aumenta el impacto en caso de explotación exitosa.

Detalles de la vulnerabilidad

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.

Puntos técnicos principales

  • Punto de entrada. Los objetos 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.).
  • Mecanismo de explotación. Un 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.
  • Condiciones necesarias. Para una explotación exitosa se requiere: una versión vulnerable de ingress-nginx; la capacidad de enviar un 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.

admission

¿Por qué es peligroso? — Consecuencias de la explotación

La explotación exitosa otorga ejecución de código en el contenedor ingress-nginx, lo que generalmente permite:

  • obtener el token de la serviceAccount del controlador y acceder a la API de Kubernetes;
  • leer Secrets y otra información confidencial en los namespaces accesibles;
  • crear/modificar recursos del clúster y ampliar el acceso (escalada de privilegios, movimiento lateral);
  • en algunos casos, la toma completa del clúster.

Observaciones de comportamiento y detección

  • En condiciones normales de funcionamiento del controlador, no hay flujo de solicitudes hacia el Admission Controller; el validating webhook es un componente interno que opera dentro del clúster. Durante la explotación se observa una anomalía: en la tarjeta de red (por ejemplo, Luntry), aparecen conexiones entrantes a 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.
  • El análisis de la tarjeta de red del clúster proporciona una visión de las interacciones entre microservicios; seleccionando el Deployment ingress-nginx en el namespace, se pueden ver las conexiones entrantes/salientes. La aparición de conexiones entrantes al endpoint de admisión en el momento del ataque es un indicador claro de compromiso.
  • Para detectar intentos de explotación, es útil monitorear: solicitudes POST al validating webhook, creación de objetos Ingress atípicos, invocaciones de nginx -t y reinicios repentinos del controlador, así como operaciones inesperadas de escritura de archivos por parte del proceso ingress-nginx.

Contexto: ¿Qué es el controlador Ingress NGINX y por qué es importante?

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.

Por qué el validating webhook se convierte en un vector de ataque conveniente

  • Por defecto, el validating webhook del controlador es accesible dentro del espacio de red de Kubernetes y, a menudo, no requiere autenticación adicional al acceder a su dirección (por ejemplo, validate.nginx.ingress.kubernetes.io). Esto facilita su invocación desde dentro del clúster.
  • La combinación: amplia distribución del controlador + su acceso de red + permisos potencialmente amplios de la serviceAccount = una combinación crítica que proporciona una ruta efectiva para el compromiso.
  • En la práctica, obtener el «primer punto de entrada» en un clúster no es tan difícil: las aplicaciones a menudo contienen vulnerabilidades que conducen al compromiso de un contenedor individual; a partir de ahí, un atacante desde ese contenedor puede invocar webhooks internos. Además, vulnerabilidades explotables como SSRF en aplicaciones web se utilizan con frecuencia para iniciar solicitudes hacia la red interna del clúster y aprovechar dichos webhooks.

Descripción repetida de la cadena de explotación (resumida)

  1. El atacante obtiene la capacidad de enviar solicitudes a la red de pods o acceder directamente al validating webhook.
  2. Se crea un Ingress / AdmissionReview especialmente manipulado, donde ciertos campos contienen cadenas maliciosas que no han pasado el filtrado adecuado.
  3. El controlador genera nginx.conf basado en estos datos de entrada y ejecuta nginx -t / otras operaciones de verificación.
  4. Los fragmentos inyectados provocan la ejecución de comandos/scripts o la escritura/ejecución de archivos en el contexto del proceso del controlador.
  5. Una vez obtenida la ejecución, el atacante extrae el token de la serviceAccount, accede a la API de Kubernetes y continúa el movimiento y la escalada dentro del clúster.

Observaciones sobre compatibilidad con otras vulnerabilidades

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.


Descargar herramienta