Por Mid 
El Vulnerabilidad Ingress Nginx CVE-2025-1974 es uno de los fallos más graves publicados en 2025 contra el controlador ingress-nginx del proyecto Kubernetes: alcanza CVSS 9.8 y, combinado con otros defectos del mismo lote, permite que un atacante en la red de pods abuse del Validating Admission Controller para inyectar configuración maliciosa y, en escenarios habituales, avanzar hacia un compromiso amplio del clúster. En este análisis resumimos qué ocurrió, quién está expuesto y qué medidas tomó el equipo de mantenimiento.
- Qué aprenderás: alcance real (incluido el dato del “40% de clústeres”), cadena de ataque y diferencia entre parchear y mitigar.
- Acción inmediata: versiones corregidas, mitigación temporal desactivando webhooks y checklist con
kubectl.
Contenido
Contexto: ingress-nginx en Kubernetes
En Kubernetes, un Ingress describe cómo exponer servicios HTTP/HTTPS hacia el exterior. Un controlador de Ingress materializa esa definición: ingress-nginx es la implementación mantenida por la comunidad Kubernetes que traduce objetos Ingress a configuración de nginx. Su popularidad es enorme: según el comunicado oficial, está presente en más del 40 % de los clústeres, lo que convierte cualquier vulnerabilidad crítica en un problema de superficie masiva.
Si trabajas con stacks que ya documentamos en el blog, conviene cruzar esta alerta con buenas prácticas de despliegue y políticas; por ejemplo, reforzar admission y políticas con herramientas como Kyverno en Kubernetes o revisar el ciclo de vida de charts en Helm Kubernetes.
¿Qué es la Vulnerabilidad Ingress Nginx CVE-2025-1974?
La Vulnerabilidad Ingress Nginx CVE-2025-1974 afecta a la forma en que ingress-nginx integra el Validating Admission Controller: un componente que valida los objetos Ingress antes de admitirlos. El fallo permite inyección de configuración abusando de esa vía; el vector es AV:N (red), complejidad baja, sin privilegios previos en el sentido clásico de credenciales de usuario, y el impacto en confidencialidad, integridad y disponibilidad es alto según el vector CVSS 3.1 publicado por FIRST.
El matiz más incómodo, descrito por el blog oficial de Kubernetes, es que la explotación no exige que el atacante pueda crear objetos Ingress en el clúster: basta con estar en la red de pods, donde en muchos despliegues hay lateral movement amplio. Por eso la Vulnerabilidad Ingress Nginx CVE-2025-1974 eleva el riesgo frente a compromisos parciales de workload o contenedores vecinos.
Vulnerabilidad Ingress Nginx CVE-2025-1974: cronología
La divulgación coordinada se produjo en marzo de 2025, con parches simultáneos en las ramas de mantenimiento del controlador y comunicación pública del Kubernetes Security Response Committee. Los investigadores de Wiz (Nir Ohfeld, Sagi Tzadik, Ronen Shustin, Hillai Ben-Sasson) reportaron de forma responsable y colaboraron con mantenedores (entre ellos Marco Ebert y James Strong) para cerrar el conjunto de fallos antes de que se generalizaran pruebas de concepto.
Para equipos de operaciones, la Vulnerabilidad Ingress Nginx CVE-2025-1974 debe figurar en el mismo tipo de playbooks que usáis para Patch Tuesday o alertas CISA: ventana de cambio prioritaria, posible excepción de freeze y revisión de inventario de imágenes. Si gestionáis múltiples clústeres, centralizad la versión del chart de Helm o del manifiesto estático y validad con CI que ningún entorno queda en una etiqueta anterior a v1.12.1 / v1.11.5.
Lote de marzo 2025 y CVSS
La Vulnerabilidad Ingress Nginx CVE-2025-1974 no vino sola: el mismo anuncio incluyó cuatro mejoras adicionales en el manejo de fragmentos de configuración de nginx susceptibles a objetos Ingress maliciosos, con riesgo de filtración de Secrets accesibles para el controlador. Por defecto, ingress-nginx puede acceder a secretos de forma amplia en el clúster; un Ingress manipulado podía inducir comportamientos indebidos del daemon nginx, incluyendo exposición de material criptográfico.
Los mantenedores publicaron parches en las series ingress-nginx v1.12.1 y v1.11.5, cerrando cinco vulnerabilidades del conjunto (la más grave es la Vulnerabilidad Ingress Nginx CVE-2025-1974). Las entradas de seguimiento en el proyecto Kubernetes incluyen los issues CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098 y CVE-2025-1974.
Impacto: de Ingress a secreto y takeover
La cadena típica descrita por el equipo de respuesta de seguridad de Kubernetes combina:
- Superficie: controladores Ingress maliciosos o tráfico en la CNI que llegue a abusar del validador.
- Exposición de Secrets: configuración nginx manipulada filtrando valores sensibles a los que el controlador ya tiene acceso.
- Escalada: movimiento desde un pod comprometido hacia el plano de control de ingress-nginx o datos de otros namespaces, según RBAC y políticas de red.
Para equipos que ya siguen incidentes recientes en infraestructura, el patrón recuerda alertas como VMware ESXi Zero-Day: la clave es parchear rápido y reducir blast radius con segmentación. Puedes ampliar contexto en la categoría Vulnerabilidades del sitio.
Vulnerabilidad Ingress Nginx CVE-2025-1974: riesgo para equipos DevOps
Desde la perspectiva de DevSecOps, la Vulnerabilidad Ingress Nginx CVE-2025-1974 ilustra tres lecciones operativas. Primera: los controladores de entrada no son “solo networking”; conviven con secretos y con la capacidad de influir en el dataplane. Segunda: la superficie de explotación incluye la CNI y la política de red: un namespace comprometido no debería poder alcanzar el API del admission webhook del controlador sin controles. Tercera: la visibilidad importa — integrar la versión de ingress-nginx en vuestro CMDB o en informes de Kubeflow Kubernetes y otros stacks no es burocracia, es reducción de tiempo medio de parcheo.
En organizaciones multicloud, alinead el proceso con el equipo de plataforma: el mismo paquete vulnerable puede estar presente en EKS, GKE o kubespray si el chart o el operador fija una versión antigua del binario. Documentad excepciones y fechas de expiración; la mitigación temporal (webhook desactivado) deja de ser aceptable en cuanto exista ventana de mantenimiento.
Los auditores internos pueden cruzar esta alerta con controles de backup y continuidad: un incidente en el plano de control de entrada no sustituye la necesidad de copias inmutables y pruebas de restauración, pero sí exige que las rotaciones de credenciales y certificados expuestos vía Ingress se revisen si hubo ventana de explotación no detectada.
Mitigación y actualización obligatoria
La recomendación oficial es actualizar de inmediato a las versiones parcheadas; la guía de upgrade está en la documentación del proyecto ingress-nginx. Si no puedes desplegar el parche al momento, la mitigación interina consiste en desactivar el Validating Admission Controller:
- Helm: reinstalar fijando
controller.admissionWebhooks.enabled=false. - Instalación manual: eliminar el
ValidatingWebhookConfigurationllamadoingress-nginx-admissiony quitar--validating-webhookdel despliegue del controlador.
Es una medida temporal: al actualizar, debes volver a habilitar el webhook para recuperar las validaciones que evitan Ingress rotos en producción.
Para comprobar si usas el controlador:
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
Si ves pods del controlador, asume exposición hasta completar el parcheo. En entornos regulados, documenta el cambio y enlaza el boletín interno con el issue CVE-2025-1974 en GitHub.
| Acción | Objetivo | Notas |
|---|---|---|
| Upgrade a v1.12.1 o v1.11.5+ | Eliminar la Vulnerabilidad Ingress Nginx CVE-2025-1974 y CVEs asociadas | Ruta preferida; revisar notas de migración del chart |
| Deshabilitar admission webhook | Reducir probabilidad de abuso del validador | Temporal; reactivar tras parcheo |
| Revisión de NetworkPolicy | Limitar qué pods hablan con el servicio de admission | Defensa en profundidad |
| Inventario de imágenes | Detectar controladores antiguos en edge clusters | CI/CD, scanners de registro |
Los responsables de plataforma suelen comparar este tipo de incidentes con brechas de cadena de suministro en capas superiores: el daño no es solo “un CVE más”, sino la posibilidad de movimiento lateral desde cargas de trabajo con bajo privilegio hacia datos de otros equipos. Por eso la comunicación ejecutiva debe incluir el dato del CVSS 9.8 y el alcance del “40 % de clústeres” citado por Kubernetes, siempre como orden de magnitud orientativa basada en estadísticas de adopción, no como censo exacto de vuestra industria.
Preguntas frecuentes
¿Afecta a todos los Ingress controllers? No. Solo al proyecto ingress-nginx (imagen/community). Otros controladores (Traefik, HAProxy Ingress, cloud LB) no están cubiertos por este CVE.
¿La Vulnerabilidad Ingress Nginx CVE-2025-1974 requiere cuenta de administrador? El riesgo destacado es la combinación con acceso a la red de pods; no se describe como un simple “click” remoto desde Internet sin más superficie, pero el impacto en entornos mal segmentados es crítico.
¿Hay exploit público? El anuncio enfatiza la gravedad y la necesidad de parcheo; para detalles técnicos actualizados sigue el issue oficial y el blog de Kubernetes citados arriba.
¿Qué versión instalar? Mantén al menos v1.12.1 o v1.11.5 según tu rama soportada; verifica el chart o manifest exacto que despliegas.
Fuentes y lecturas
- Kubernetes Blog — Ingress-nginx CVE-2025-1974: What You Need to Know (marzo 2025; enlaces revisados mayo 2025 según el propio artículo).
- GitHub — issue CVE-2025-1974.
- Agradecimientos en el anuncio original a investigadores de Wiz (responsable disclosure).
Artículo de análisis basado en fuentes públicas. Actualizado a marzo de 2026 para programación editorial.
Conclusión: Vulnerabilidad Ingress Nginx CVE-2025-1974
La Vulnerabilidad Ingress Nginx CVE-2025-1974 resume por qué los controladores de entrada deben tratarse como componentes de seguridad crítica: popularidad masiva, validación en línea y acceso privilegiado a secretos hacen que un solo defecto de admission se convierta en riesgo sistémico. Prioriza el parcheo, documenta la ventana de mitigación si deshabilitas webhooks y revisa la segmentación de red entre pods antes del próximo pentest.