Vulnerability Analysis on KnightLi Blog

Cómo comprobar CVE-2026-42945: condiciones de Nginx Rift, revisión de versiones y recomendaciones de actualización

Fri, 15 May 2026 17:55:42 +0800

CVE-2026-42945 es una vulnerabilidad de seguridad en NGINX Open Source y NGINX Plus. También se la conoce como Nginx Rift. El problema está en ngx_http_rewrite_module, y el tipo de vulnerabilidad es heap-based buffer overflow.

Este tipo de noticia se convierte con facilidad en titulares como “oculta durante 18 años”, “control remoto sin contraseña” o “30% de servidores afectados”. Esas frases se propagan bien, pero al leer los parches y la descripción de NVD conviene separar el riesgo en hechos concretos: el problema es grave y no requiere una cuenta iniciada; pero no todos los Nginx quedan comprometidos automáticamente. Para activarlo hacen falta condiciones específicas de configuración rewrite y de solicitud.

Empezar por la descripción oficial

La descripción de NVD para CVE-2026-42945 puede resumirse así:

Afecta a NGINX Plus y NGINX Open Source.
La vulnerabilidad está en ngx_http_rewrite_module.
El problema puede activarse cuando una directiva rewrite va seguida de rewrite, if o set, se usan grupos de captura PCRE sin nombre como $1 y $2, y la cadena de reemplazo contiene un signo de interrogación ?.
Un atacante no autenticado puede enviar una solicitud construida para activar la vulnerabilidad.
El resultado puede ser un heap buffer overflow y el reinicio de un proceso worker de NGINX.
Si ASLR está desactivado en el sistema, la ejecución de código es posible.

F5, como CNA, asigna estas puntuaciones:

CVSS v4.0: 9.2, Critical.
CVSS v3.1: 8.1, High.
CWE: CWE-122 Heap-based Buffer Overflow.

Así que no se trata de un caso normal de “mala configuración que causa un 404”. Es una vulnerabilidad de seguridad de memoria cubierta por una corrección oficial de Nginx.

Qué afirmaciones necesitan contexto

Primero, “sin contraseña” debe entenderse como ataque no autenticado. Es decir, el atacante no necesita entrar a un panel de administración de Nginx, obtener SSH ni tener una cuenta de la aplicación. Pero eso no significa que cualquier Nginx expuesto a internet pueda tomarse sin más.

Segundo, “control remoto directo” depende de las condiciones. La formulación oficial más prudente es que la vulnerabilidad puede causar reinicios de procesos worker; en sistemas donde ASLR está desactivado, la ejecución de código es un resultado posible. En entornos con ASLR activado, endurecimiento de compilación de la distribución y permisos de ejecución restringidos, la ruta de riesgo es más compleja.

Tercero, “30% de servidores afectados” no debe interpretarse como “toda la cuota de mercado de Nginx equivale a superficie expuesta”. La exposición real depende de la versión, de si el módulo afectado está presente, de si existe la configuración rewrite concreta, de si la distribución ya aplicó backport del parche y del estado de endurecimiento del entorno donde corre Nginx.

La forma más precisa de decidirlo es sencilla: si ejecutas Nginx en producción, revísalo pronto; pero no decidas si estás afectado solo por el porcentaje de un titular.

Cómo determinar el alcance afectado

Según la información de publicación de nginx.org, las versiones nginx-1.30.1 stable y nginx-1.31.0 mainline publicadas el 13 de mayo de 2026 incluyen varias correcciones de seguridad, entre ellas el buffer overflow de ngx_http_rewrite_module registrado como CVE-2026-42945.

Si usas código fuente oficial de Nginx o paquetes oficiales, prioriza:

NGINX Open Source stable: actualizar a 1.30.1 o posterior.
NGINX Open Source mainline: actualizar a 1.31.0 o posterior.
NGINX Plus: revisar la versión corregida para la rama correspondiente de F5.

Si usas Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, Alpine, imágenes de contenedor, Plesk, paneles de control, Ingress Controller o componentes administrados por un proveedor cloud, no mires solo la versión upstream que muestra nginx -v. Muchas distribuciones aplican backport de parches de seguridad a versiones antiguas de paquetes. La cadena de versión puede parecer vieja aunque el parche ya esté incorporado.

Comprobación de urgencia en un minuto

Usa estas preguntas para clasificar el riesgo rápidamente:

¿Este Nginx está expuesto directamente a internet, o forma parte de un API Gateway, proxy inverso, balanceador de carga o capa de entrada Ingress?
¿Usas paquetes oficiales de Nginx, compilaciones desde código fuente, paneles de terceros o imágenes de contenedor sin haber confirmado el estado de corrección de CVE-2026-42945?
¿La configuración contiene reglas rewrite complejas, especialmente rewrite, if o set consecutivos y capturas sin nombre como $1 y $2?
¿Algún destino rewrite incluye rutas de solicitud, parámetros de consulta u otra entrada controlada por el usuario?
¿El sistema está poco endurecido, por ejemplo con ASLR desactivado, workers con demasiados privilegios o permisos de contenedor demasiado amplios?

Si se cumplen los dos primeros puntos y todavía no se revisó la configuración rewrite, trátalo como alta prioridad. Los puntos de entrada públicos, entornos compartidos, Kubernetes Ingress, proxies de borde y Nginx que transportan tráfico de login o API deben actualizarse o sustituirse primero por paquetes con corrección confirmada.

Cómo confirmar la corrección en Debian / Ubuntu / RHEL / Alpine

Los usuarios de distribuciones no deben mirar solo nginx -v. Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux y Alpine suelen aplicar backport de parches de seguridad a ramas estables, así que la versión visible puede seguir siendo inferior a 1.30.1 o 1.31.0 de nginx.org.

En Debian / Ubuntu, revisa advisories de seguridad, changelog del paquete y candidatos de actualización:

nginx -v
nginx -V
apt list --upgradable | grep nginx
apt changelog nginx | grep -i "CVE-2026-42945"

En RHEL / AlmaLinux / Rocky Linux, revisa actualizaciones de seguridad y changelog del paquete:

1
2

yum updateinfo list security | grep -i nginx
rpm -q --changelog nginx | grep -i "CVE-2026-42945"

En Alpine, revisa la versión instalada y las actualizaciones de la rama de seguridad:

1
2

apk info -v nginx
apk version -v nginx

Si el gestor de paquetes, el advisory de la distribución o el advisory del proveedor dice explícitamente que CVE-2026-42945 está corregido, puedes tratarlo como backport aplicado aunque el número de versión upstream parezca antiguo. A la inversa, si la versión parece alta pero el origen no está claro, confirma igualmente la fecha de compilación y el origen del parche.

Cómo comprobar imágenes de contenedor e Ingress Controller

En entornos de contenedores, revisa el Nginx dentro de la imagen, no solo el host. Primero confirma la versión realmente incluida:

1
2

docker run --rm your-nginx-image nginx -v
docker run --rm your-nginx-image nginx -V

También revisa si la imagen base fue actualizada. Si la imagen se construye sobre Debian, Ubuntu, Alpine o paquetes de distribución, el criterio vuelve a ser el advisory y el changelog de esa distribución. Reiniciar una imagen vieja no sirve; la imagen en sí debe reconstruirse o reemplazarse.

En Kubernetes Ingress, confirma tres cosas:

Si el proyecto Ingress Controller publicó un advisory o una versión corregida para CVE-2026-42945.
Si el digest de la imagen del controller que corre en el clúster realmente cambió, no solo el tag.
Si la versión de Nginx integrada, los parámetros de compilación y la configuración de plantillas del controller siguen conteniendo reglas rewrite de alto riesgo.

Puedes empezar revisando la imagen en ejecución:

1
2

kubectl -n ingress-nginx get pods -o wide
kubectl -n ingress-nginx describe pod <pod-name> | grep -i image

Si usas un Ingress o gateway administrado por un proveedor cloud, revisa también el advisory del servicio correspondiente. Los componentes administrados normalmente no se corrigen con un apt upgrade ejecutado por el usuario; necesitas la corrección del proveedor o cambiar a una versión ya corregida.

Qué patrones rewrite merecen atención

Esta vulnerabilidad está relacionada con la configuración rewrite. Empieza buscando en la configuración de Nginx:

1
2

grep -R "rewrite" /etc/nginx -n
grep -R "\\$[0-9]" /etc/nginx -n

Presta atención a patrones como este:

`1`	`rewrite ^/old/(.*)$ /new/$1? permanent;`

Las capturas sin nombre como $1 y $2, junto con el ? en el destino de reemplazo, forman parte de las condiciones clave descritas por las fuentes oficiales. Durante la revisión, presta especial atención a:

Un rewrite seguido de otro rewrite, if o set.
Capturas amplias como (.*) o (.+) reutilizadas como $1 o $2.
Destinos rewrite que contienen ? para añadir o descartar parámetros de consulta.
Entradas rewrite que provienen de rutas públicas, Host, URI, parámetros o valores controlados por upstream.
Reglas rewrite generadas por paneles, gateways, anotaciones de Ingress o plantillas.

Si no puedes actualizar de inmediato, aplica mitigaciones temporales:

Reducir reglas rewrite complejas.
Sustituir capturas sin nombre por capturas con nombre más claras.
Evitar concatenar ? innecesarios en cadenas de reemplazo.
Añadir reglas WAF o de proxy inverso para entradas de alto riesgo.
Confirmar que ASLR está activado.
Reducir privilegios de los workers de Nginx y verificar systemd sandbox, SELinux/AppArmor y otros endurecimientos.

Estas medidas son mitigaciones, no sustituyen al parche.

Prioridad de remediación

Prioriza por superficie expuesta:

Puntos de entrada Nginx expuestos a internet.
Proxies inversos, API Gateway y gateways de borde.
Nginx en entornos multiinquilino.
Kubernetes Ingress Controller.
Plesk, paneles de control, imágenes de marketplace cloud y otros componentes que incluyen Nginx.
Nginx internos que transportan tráfico crítico de negocio.

Cómo verificar después de actualizar: nginx -t, reload y estado de workers

Después de actualizar, no te quedes solo con el mensaje de éxito del gestor de paquetes. Confirma que la configuración, los procesos y el binario real ya cambiaron. Primero valida la configuración:

`1`	`nginx -t`

Si no hay errores, recarga de forma suave:

`1`	`systemctl reload nginx`

Si la actualización del paquete sustituyó el binario, confirma que los workers antiguos salieron:

`1`	`ps aux \| grep nginx`

También puedes revisar la hora de inicio del proceso master y la ruta del binario para asegurarte de que el servicio en ejecución no sea un proceso antiguo que sigue residente. Si hace falta, programa una ventana de mantenimiento y reinicia el servicio para evitar que workers o contenedores antiguos sigan procesando solicitudes.

En contenedores e Ingress, confirma también que el rollout de la nueva imagen se completó de verdad:

1
2

kubectl -n ingress-nginx rollout status deployment/<deployment-name>
kubectl -n ingress-nginx get pods -o wide

La verificación clave no es “el comando se ejecutó”, sino “el tráfico en producción ya lo atienden procesos Nginx que incluyen la corrección”.

No ignores el mismo lote de correcciones de Nginx

Las versiones 1.30.1 y 1.31.0 publicadas por nginx.org el mismo día no solo corrigen CVE-2026-42945. La información de publicación también menciona HTTP/2 request injection, SCGI/uWSGI buffer overread, charset module buffer overread, HTTP/3 address spoofing, OCSP resolver use-after-free y otros problemas.

Eso significa que un entorno de producción no debería limitarse a una regla temporal para un solo CVE. Conviene tratar esta ronda de seguridad de Nginx como una actualización completa.

Resumen

El punto clave de CVE-2026-42945 no es “todos los Nginx pueden tomarse al instante”. Es una vulnerabilidad de seguridad de memoria presente durante mucho tiempo en el módulo rewrite, que puede activarse mediante solicitudes no autenticadas bajo configuraciones concretas. El resultado directo más claro es el fallo y reinicio de workers; en entornos más débiles, como sistemas con ASLR desactivado, el riesgo de ejecución de código aumenta.

Para equipos de operaciones, el orden de actuación es simple:

Confirmar el origen y la versión de Nginx.
Revisar advisories de la distribución, F5, nginx.org o proveedor cloud.
Actualizar cuanto antes a una versión corregida o a un paquete de seguridad de la distribución.
Revisar configuraciones rewrite complejas, especialmente combinaciones de $1, $2 y ?.
Confirmar ASLR, aislamiento de privilegios y estado de recarga del servicio.

El titular puede asustar. La corrección debe ser tranquila: confirmar exposición, actualizar y después limpiar reglas rewrite de alto riesgo.

Referencias

Copy Fail CVE-2026-31431: riesgo de escape de contenedor en la ruta de copia de archivos del kernel Linux

Fri, 01 May 2026 18:42:34 +0800

Copy Fail es una vulnerabilidad en la ruta de copia de archivos del kernel Linux, registrada como CVE-2026-31431. El análisis de Bugcrowd la describe como un problema de nivel kernel que merece atención: bajo condiciones específicas, un usuario sin privilegios puede abusar de la lógica de copia de archivos para provocar escrituras no autorizadas, lo que puede llevar a escalada de privilegios o escape de contenedor.

Desde una perspectiva de riesgo, no es una vulnerabilidad normal de capa de aplicación. El problema ocurre en la ruta del kernel que maneja copia de archivos y comportamiento de page cache, por lo que su impacto puede extenderse a contenedores, hosts compartidos, runners de CI/CD, plataformas PaaS y entornos Linux multi-tenant. Si un atacante ya puede ejecutar código con pocos privilegios en un sistema, la vulnerabilidad puede convertirse en un escalón para romper límites de aislamiento.

Dónde vive aproximadamente la vulnerabilidad

Copy Fail está relacionada con capacidades de copia de archivos del kernel Linux. Linux moderno ofrece varias rutas eficientes de copia, como copy_file_range, rutas tipo splice y optimizaciones de copia de datos entre distintos sistemas de archivos. Estos mecanismos están diseñados para reducir movimiento de datos entre espacio de usuario y espacio de kernel y mejorar el rendimiento de copia de archivos grandes.

El problema es que las rutas de copia de alto rendimiento suelen reutilizar page cache, offsets de archivo, comprobaciones de permisos y callbacks de sistemas de archivos. Si una condición de borde no se maneja con suficiente rigor, el kernel puede realizar una escritura en el contexto de permisos equivocado o exponer páginas de datos que el atacante no debería controlar.

El riesgo central de Copy Fail se puede resumir así:

el atacante no necesita privilegios root;
el punto de entrada del ataque proviene de capacidades comunes de copia de archivos;
la lógica afectada se ejecuta en espacio de kernel;
en entornos de contenedores, la vulnerabilidad puede saltarse aislamiento de namespaces y montajes;
una explotación exitosa puede escribir contenido del host que el contenedor no debería poder modificar.

Por eso ha llamado la atención. La seguridad de contenedores depende del aislamiento que proporciona el kernel Linux. Cuando una ruta del propio kernel permite escrituras no autorizadas, el límite del contenedor se vuelve frágil.

Por qué los escenarios de contenedores son más sensibles

Los contenedores no son máquinas virtuales. Los procesos dentro de un contenedor comparten el mismo kernel Linux con el host y se aíslan mediante mecanismos como namespaces, cgroups, capabilities, seccomp y AppArmor/SELinux.

Si una vulnerabilidad existe en un servicio de espacio de usuario, normalmente afecta solo a un contenedor o un proceso. Pero si la vulnerabilidad está en el kernel, especialmente una que puede activar un usuario sin privilegios, un atacante puede influir en el host desde dentro de un contenedor.

Ahí es donde Copy Fail se vuelve peligroso. Muchas plataformas permiten a usuarios enviar jobs de build, ejecutar scripts, iniciar contenedores o ejecutar plugins. Mientras un atacante pueda ejecutar código dentro de un contenedor, puede intentar usar la ruta de copia de archivos del kernel para romper el aislamiento.

Entornos de alto riesgo incluyen:

cargas no confiables en clusters Kubernetes;
runners compartidos en plataformas CI/CD;
plataformas sandbox que permiten a usuarios subir y ejecutar código;
hosts Linux multi-tenant;
entornos PaaS contenerizados;
sistemas que ejecutan plugins o extensiones de terceros.

Si estos entornos ejecutan kernels afectados y no tienen restricciones adicionales, el riesgo aumenta de forma significativa.

El impacto depende del estado de parcheo del kernel

No se puede juzgar este tipo de vulnerabilidad solo por el nombre de la distribución. Para la misma versión de Ubuntu, Debian, RHEL, Fedora o Arch, la exposición depende del paquete de kernel que realmente está en ejecución y de si la distribución hizo backport del arreglo.

Durante el triage, prioriza tres comprobaciones:

La versión del kernel actualmente en ejecución.
Si el aviso de seguridad de la distribución menciona CVE-2026-31431.
Si el proveedor cloud o la plataforma gestionada parcheó el kernel del host.

Primero puedes confirmar la versión del kernel en el sistema:

`1`	`uname -a`

Luego revisa avisos de seguridad de la distribución, changelogs del kernel o comunicados de la plataforma cloud. No juzgues la seguridad solo por la versión mayor, porque muchas distribuciones empresariales hacen backport de correcciones de seguridad a ramas de kernel antiguas.

Ideas de mitigación temporal

La solución más confiable sigue siendo actualizar el kernel. Pero en entornos donde los parches no pueden desplegarse de inmediato, puedes reducir exposición primero.

Direcciones comunes de mitigación incluyen:

impedir que usuarios no confiables ejecuten contenedores privilegiados;
evitar montar rutas sensibles del host dentro de contenedores;
endurecer capabilities de contenedores, especialmente evitando CAP_SYS_ADMIN innecesario;
usar seccomp, AppArmor o SELinux para restringir syscalls peligrosas y acceso a archivos;
mover cargas no confiables a aislamiento más fuerte mediante máquinas virtuales;
destruir runners de CI/CD por job en lugar de reutilizar el mismo host durante mucho tiempo;
monitorear escrituras anómalas de archivos, cambios de permisos y señales de escape de contenedor.

Estas medidas no reemplazan parches. Su papel es reducir la probabilidad de explotación y el impacto, especialmente antes de que los parches lleguen a producción.

Prioridad de parcheo

Prioriza la remediación según el riesgo del entorno.

Parchear primero:

plataformas que exponen ejecución de contenedores a usuarios externos;
nodos CI/CD que ejecutan código no confiable;
nodos Kubernetes multi-tenant;
sistemas con plugins o ejecución de scripts definidos por usuarios;
máquinas de desarrollo compartidas, equipos de enseñanza y plataformas de laboratorio.

Prioridad relativamente menor:

escritorios de un solo usuario;
hosts internos que solo ejecutan servicios confiables;
entornos que ya aíslan código no confiable mediante máquinas virtuales.

Incluso cuando el riesgo es menor, sigue siendo mejor actualizar el kernel mediante la distribución. Las vulnerabilidades de kernel a menudo se encadenan en ataques más complejos, y retrasar parches rara vez aporta mucho beneficio.

Checklist para equipos de operaciones

Puedes procesarlo en este orden:

Inventariar todos los hosts Linux y nodos de contenedores.
Marcar máquinas que ejecutan código no confiable.
Comprobar versión actual de kernel y avisos de seguridad de la distribución.
Actualizar primero los nodos de alto riesgo.
Aplicar políticas temporales de aislamiento a nodos que no pueden actualizarse de inmediato.
Revisar configuración del runtime de contenedores y eliminar privilegios y montajes de host innecesarios.
Reiniciar nodos después de actualizar y confirmar que el nuevo kernel está realmente en ejecución.
Mantener registros de cambios para auditoría posterior.

Instalar un paquete de kernel no significa que el sistema ya esté ejecutando el nuevo kernel. Debes reiniciar después de actualizar y confirmar de nuevo:

`1`	`uname -a`

Resumen

El punto clave de Copy Fail / CVE-2026-31431 no es que una aplicación se cierre, sino que existe un problema de límite de permisos en la ruta de copia de archivos del kernel Linux. Da a código sin privilegios una oportunidad de tocar rutas de escritura con mayor privilegio, por lo que merece atención especial en entornos de contenedores y multi-tenant.

Al manejar este tipo de vulnerabilidad, las dos acciones más importantes son:

seguir cuanto antes los parches de kernel de tu distribución o proveedor cloud;
antes de desplegar parches, restringir código no confiable, contenedores privilegiados y montajes sensibles del host.

Para escritorios personales, quizá no sea un motivo de pánico inmediato. Pero para equipos que operan plataformas de contenedores, CI/CD, sandboxes y hosts compartidos, debe tratarse como una actualización de seguridad de kernel de alta prioridad.

Referencias: