Gravedad: CRÍTICA (CVSS 9.8) | Acción obligatoria: actualice de inmediato Varias vulnerabilidades en NGINX Ingress controller permiten que los atacantes con acceso a la red de pods ejecuten código arbitrario. Además, pueden acceder a todos los Secrets del clúster sin credenciales ni privilegios administrativos. Si su clúster ACK ejecuta NGINX Ingress controller con el admission webhook habilitado, trate esta situación como una emergencia y actúe ahora.
¿Estoy afectado?
Utilice el siguiente árbol de decisiones para determinar si su clúster está en riesgo.
Paso 1: compruebe si NGINX Ingress controller está instalado
kubectl get pods -n kube-system --selector app=ingress-nginxSi no se devuelve ningún pod, su clúster no tiene instalado NGINX Ingress controller y no está afectado. No se requiere ninguna acción adicional.
Si se devuelven pods, continúe con el paso 2.
Paso 2: compruebe qué versión se está ejecutando
Versiones afectadas de NGINX Ingress controller:
Todas las versiones anteriores a v1.11.5
v1.12.0
Si su clúster ejecuta v1.11.5, v1.12.1 o cualquier versión posterior, ya cuenta con una versión parcheada. No se requiere ninguna acción adicional.
Para conocer la versión instalada, consulte How to check your installation method and version.
Paso 3: compruebe si el admission webhook está habilitado
Los clústeres con el admission webhook deshabilitado no están afectados por la vulnerabilidad más crítica (CVE-2025-1974). Sin embargo, las vulnerabilidades de inyección basadas en anotaciones (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-24513) siguen aplicando si algún usuario tiene permisos de escritura sobre los recursos Ingress. Aun así, debe actualizar.
-
Instalación mediante complementos: ejecute el siguiente comando. Si no se encuentra el recurso, el admission webhook está deshabilitado.
kubectl get validatingwebhookconfigurations ingress-nginx-admission Instalación desde Marketplace: consulte la información básica de la aplicación correspondiente y compruebe si existe algún recurso de tipo
ValidatingWebhookConfiguration.
Resumen
|
Condition |
Risk level |
|
NGINX Ingress controller no instalado |
No afectado |
|
Instalado, versión >= v1.11.5 (1.11.x) o >= v1.12.1 (1.12.x) |
No afectado (ya parcheado) |
|
Instalado, versión afectada, admission webhook deshabilitado |
Riesgo reducido (actualice de todas formas) |
|
Instalado, versión afectada, admission webhook habilitado |
Afectado: actúe de inmediato |
Cómo comprobar el método de instalación y la versión
NGINX Ingress controller se instala en los clústeres ACK por dos vías: desde la página Add-ons o desde Marketplace (gráfico de Helm). Los pasos de corrección varían según el método utilizado.
Instalado desde la página Add-ons
Método 1: comprobación en la página Add-ons
Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Clusters.
En la página Clusters busque el clúster que desea gestionar y haga clic en su nombre. En el panel de navegación izquierdo, haga clic en Add-ons.
En la página Add-ons busque Nginx Ingress Controller. Luego, en la tarjeta del componente, compruebe si está instalado y cuál es su versión actual.
Método 2: consulta con kubectl
kubectl get pods -n kube-system --selector app=ingress-nginxInstalado desde Marketplace (gráfico de Helm)
Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Clusters.
En la página Clusters busque el clúster que desea gestionar y haga clic en su nombre. En el panel de navegación izquierdo, elija Applications > Helm.
En la lista de Helm, compruebe si
ack-ingress-nginxoack-ingress-nginx-v1aparece en la columna Chart Name. La columna Application Version muestra la versión actual del componente NGINX Ingress controller.
Detalles de las vulnerabilidades
La comunidad de Kubernetes divulgó cinco vulnerabilidades de seguridad en NGINX Ingress controller. Cuatro de ellas permiten que los atacantes inyecten configuraciones maliciosas mediante anotaciones Ingress manipuladas. La más crítica, CVE-2025-1974, permite ejecutar código sin autenticación a cualquier entidad con acceso a la red de pods y omite por completo el admission webhook.
En la práctica, cualquier carga de trabajo que se ejecute en la red de pods del clúster puede aprovechar estas vulnerabilidades. Lo mismo aplica para cualquier entidad con acceso de red al endpoint del controlador de admisión. Así, un atacante ejecuta código arbitrario dentro de NGINX Ingress controller y obtiene todos los Secrets del clúster. En muchos escenarios comunes, todos los workloads de su VPC en la nube tienen acceso a la red de pods. Incluso podría estar expuesta a cualquier persona conectada a la red corporativa. Por lo tanto, los Secrets almacenados en Kubernetes podrían quedar expuestos. Entre ellos se incluyen certificados TLS, credenciales de API y otros datos confidenciales.
|
CVE ID |
Severity |
CVSS v3.1 score |
Description |
Risk |
Reference |
|
Alta |
Los atacantes con permisos de escritura sobre recursos Ingress aprovechan la anotación |
Los atacantes pueden ejecutar código arbitrario en el contexto de NGINX Ingress controller y obtener Secrets en todo el clúster. |
|||
|
Alta |
Los atacantes con permisos de escritura sobre recursos Ingress aprovechan las anotaciones |
Los atacantes pueden ejecutar código arbitrario en el contexto de NGINX Ingress controller y obtener Secrets en todo el clúster. |
|||
|
Crítica |
Los atacantes con acceso a la red de pods omiten el admission webhook para inyectar configuraciones. |
Los atacantes pueden ejecutar código arbitrario en el contexto de NGINX Ingress controller y obtener Secrets en todo el clúster. |
|||
|
Alta |
Los atacantes con permisos de escritura sobre recursos Ingress aprovechan la anotación |
Los atacantes pueden ejecutar código arbitrario en el contexto de NGINX Ingress controller y obtener Secrets en todo el clúster. |
|||
|
Media |
NGINX Ingress controller no valida ni filtra adecuadamente los datos de entrada enviados por usuarios con permisos de escritura sobre recursos Ingress. Los atacantes aprovechan esta vulnerabilidad para crear solicitudes maliciosas e inyectar datos no autorizados en la ruta de generación del archivo de configuración. |
Se pueden desencadenar vulnerabilidades de recorrido de directorios dentro del contenedor. Esta vulnerabilidad puede provocar una denegación de servicio (DoS). Si se combina con otras vulnerabilidades, también puede filtrar algunos Secrets del clúster. |
Mitigación temporal
Si no puede actualizar de inmediato, deshabilite el admission webhook para bloquear el vector de ataque más crítico (CVE-2025-1974). Esta medida es temporal. Debe actualizar a una versión parcheada lo antes posible.
Para clústeres con NGINX Ingress controller instalado desde la página Add-ons
En la página Add-ons del clúster de destino, busque el componente Nginx Ingress Controller y deshabilite manualmente la función de admission webhook. Para más detalles, consulte Manage NGINX Ingress controller.
Para clústeres con NGINX Ingress controller instalado desde Marketplace
Elimine manualmente el admission webhook correspondiente para reducir el riesgo:
kubectl delete validatingwebhookconfigurations ingress-nginx-admissionDeshabilitar o eliminar el admission webhook elimina un mecanismo de validación previa para las configuraciones Ingress. Aunque esto mitiga la vulnerabilidad, las configuraciones Ingress inválidas ya no se rechazarán antes de entrar en vigor. Vuelva a habilitar el admission webhook después de actualizar a una versión parcheada.
Corrección: actualización a la versión parcheada
La comunidad corrigió las cinco vulnerabilidades en las siguientes versiones de NGINX Ingress controller:
v1.11.5
v1.12.1
Actualice a v1.11.5 o posterior (para la línea de versiones 1.11.x), o bien a v1.12.1 o posterior (para la línea 1.12.x). Ejecute este proceso fuera del horario de mayor tráfico.
Gestión de complementos
Si aún no lo ha hecho, deshabilite el admission webhook tal como se describe en Interim mitigation. Esto reduce el riesgo mientras prepara la actualización.
Actualice el componente NGINX Ingress controller a v1.11.5 o posterior. Consulte NGINX Ingress controller release notes para ver los detalles de la versión y siga las instrucciones de Update NGINX Ingress controller para completar la actualización.
Una vez finalizada la actualización, vuelva a habilitar el admission webhook.
Cuando termine la actualización, asegúrese de volver a habilitar la función de admission webhook. Esta función actúa como mecanismo de validación previa para las configuraciones Ingress y mejora de forma efectiva la confiabilidad y estabilidad del servicio. Antes de que surta efecto la creación o modificación de una configuración Ingress, el admission webhook le alertará sobre posibles errores. Así podrá evitar problemas operativos.
Marketplace
Si aún no lo ha hecho, elimine manualmente el admission webhook tal como se describe en Interim mitigation. Esto reduce el riesgo mientras prepara la actualización.
Revise las notas de la versión del componente en la página Marketplace o en la página Helm de la consola. Después, aplique update ack-ingress-nginx on the Marketplace page a v1.11.5 o posterior fuera del horario de mayor tráfico.
Al terminar la actualización, compruebe que el admission webhook se haya vuelto a crear como parte del despliegue del gráfico de Helm actualizado. Si no es así, vuelva a habilitarlo manualmente.
Referencias de los parches
La comunidad resolvió cada vulnerabilidad en los siguientes commits. Todos forman parte del PR #13068:
|
CVE |
Commit |
|
CVE-2025-1097 |
ingress-nginx main@06c992a |
|
CVE-2025-1098 |
ingress-nginx main@2e9f373 |
|
CVE-2025-1974 |
ingress-nginx main@0ccf4ca |
|
CVE-2025-24513 |
ingress-nginx main@cbc1590 |
|
CVE-2025-24514 |
ingress-nginx main@ab470eb |
Preguntas frecuentes
P: Mi clúster no tiene instalado NGINX Ingress controller. ¿Estoy afectado?
No. Los clústeres sin NGINX Ingress controller instalado no están afectados por ninguna de estas vulnerabilidades. No se requiere ninguna acción.
P: Deshabilité el admission webhook. ¿Sigo en riesgo?
Deshabilitar el admission webhook bloquea la vulnerabilidad más crítica (CVE-2025-1974, CVSS 9.8). Sin embargo, los atacantes con permisos de escritura sobre recursos Ingress todavía pueden aprovechar las vulnerabilidades de inyección basadas en anotaciones (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-24513). Esto ocurre sin importar la configuración del webhook. Por lo tanto, debe actualizar a una versión parcheada.
P: ¿Debo volver a habilitar el admission webhook después de actualizar?
Sí. El admission webhook funciona como mecanismo de validación previa para las configuraciones Ingress. Detecta y rechaza las configuraciones inválidas antes de que entren en vigor, lo que ayuda a prevenir interrupciones del servicio. Siempre vuelva a habilitarlo tras instalar una versión parcheada.
P: ¿Cuál es la diferencia entre las rutas de instalación mediante Add-ons y Marketplace?
NGINX Ingress controller se instala en ACK desde la página Add-ons (gestionado por el ciclo de vida de complementos de ACK) o desde Marketplace como gráfico de Helm. Los pasos de corrección difieren ligeramente. Los usuarios de Add-ons deshabilitan el webhook desde la interfaz de la consola, mientras que los usuarios de Marketplace eliminan directamente el recurso ValidatingWebhookConfiguration. Ambas rutas requieren actualizar a v1.11.5 o posterior.