F5 NGINX: tres fallos críticos, posible RCE sin autenticación

A mediados de octubre de 2026 F5 publicó correcciones para varias vulnerabilidades de NGINX, tres de ellas críticas: CVE-2026-15176, CVE-2026-93479 y CVE-2026-97205, todas con una puntuación CVSS de 9.2 (CVSS v4.0, según CSO Online). BleepingComputer y CSO Online hablan de parches fuera de ciclo (out-of-band). Un atacante remoto y sin autenticación puede explotarlas con peticiones HTTP manipuladas, pero solo con configuraciones concretas, distintas de las predeterminadas. El efecto seguro es el fallo o el reinicio del proceso worker (denegación de servicio); la ejecución de código es posible si ASLR está desactivado o se puede eludir.

Según BleepingComputer y CSO Online, F5 no tiene pruebas de explotación activa. El Centre for Cybersecurity Belgium (CCB) publicó un aviso que insta a actualizar de inmediato. Según Security Affairs, en total se corrigieron once problemas: el dato lo da solo este medio.

Productos afectados

Según BleepingComputer y CSO Online: NGINX Plus, NGINX Open Source, NGINX Ingress Controller, NGINX Gateway Fabric y NGINX Instance Manager. Las fuentes no indican las versiones vulnerables ni las corregidas: hay que consultarlas en los boletines de F5 de cada producto y, para NGINX Open Source instalado desde los paquetes de una distribución Linux, en los avisos de la distribución.

Las tres vulnerabilidades

• CVE-2026-15176: desbordamiento de búfer en el heap del proceso worker. Se produce con configuraciones que usan la directiva alias en un bloque location junto con la variable $request_filename.
• CVE-2026-93479: desbordamiento de búfer en el heap relacionado con la directiva map. Según Security Affairs afecta a las configuraciones en las que las variables de captura de la expresión regular de un map se usan antes que la variable de salida del map, o en las que una variable no almacenable en caché (non-cacheable) se usa en una expresión de cadena, en determinadas condiciones.
• CVE-2026-97205: use-after-free según Security Affairs, con E/S asíncrona de archivos (AIO) activada, cuando NGINX procesa páginas Server Side Includes (SSI) con comandos include virtual. Puede corromper la memoria o terminar el worker.

Las fuentes no coinciden en el módulo: para Security Affairs la CVE-2026-97205 está en ngx_http_core_module, CSO Online sitúa allí tanto esta como la CVE-2026-15176, mientras que BleepingComputer atribuye ambas a ngx_http_v3_module (HTTP/3). En cambio, las condiciones de configuración y las mitigaciones de F5 son las mismas en todas las fuentes, y son las que permiten saber si un servidor está expuesto.

En términos de MITRE ATT&CK, la explotación corresponde a T1190 (Exploit Public-Facing Application) y, por los fallos repetidos, a T1499.004 (Endpoint Denial of Service: Application or System Exploitation). Las fuentes no aportan indicadores de compromiso ni exploits públicos para estos tres fallos.

Impacto para las empresas europeas e italianas

NGINX actúa como proxy inverso, balanceador e ingress de Kubernetes delante de muchísimos servicios web, y a menudo es ahí donde termina el TLS. Un analista citado por CSO Online subraya que la ejecución de código en ese punto daría acceso en claro a contraseñas, cookies de sesión, tokens de API y claves privadas. Incluso sin ejecución de código, un worker que se reinicia sin parar significa servicios inaccesibles.

NGINX suele ir integrado en appliances, imágenes de contenedores y controladores de ingress, y muchos equipos lo instalan desde su distribución Linux: según el mismo analista, Amazon Linux aún indicaba como pendiente la corrección relativa a AIO. Por eso la actualización publicada por F5 no llega sola a todos los servidores. También según CSO Online, son las últimas de una serie: en mayo la CVE-2026-42945 («NGINX Rift», en el módulo rewrite) salió con una prueba de concepto pública de ejecución remota de código, y en junio llegó la CVE-2026-42530 en ngx_http_v3_module.

Para las entidades sujetas a NIS2, en especial proveedores de servicios digitales, hosting y servicios gestionados, el caso entra en la gestión de vulnerabilidades con prioridades y plazos documentados; una interrupción significativa causada por un ataque debe valorarse a efectos de la notificación al CSIRT nacional (en Italia, el CSIRT Italia de la ACN). En la sanidad, NGINX suele publicar portales para pacientes y API de aplicaciones clínicas: conviene revisarlos también.

Qué hacer ya

1. Haz el inventario de dónde se ejecuta NGINX: servidores, contenedores, controladores de ingress y appliances. nginx -V muestra la versión y los módulos compilados.
2. Revisa la configuración efectiva con nginx -T: busca alias junto con $request_filename, aio activado junto con ssi on, y bloques map con capturas sin nombre ($1, $2…).
3. Actualiza a las versiones corregidas que indica F5 para cada producto o, para los paquetes de la distribución, en cuanto la distribución las publique. Prioridad a los servidores expuestos a Internet con las configuraciones del punto 2.
4. Si no puedes actualizar enseguida, aplica las mitigaciones de F5 que recogen BleepingComputer y CSO Online:
   • CVE-2026-15176: evita la directiva alias en un bloque location o la variable $request_filename;
   • CVE-2026-97205: desactiva AIO o SSI;
   • CVE-2026-93479: usa capturas con nombre en lugar de capturas sin nombre y limita su uso al bloque con la expresión regular.
5. Comprueba que ASLR esté activo: en Linux, cat /proc/sys/kernel/randomize_va_space debe devolver 2. Según F5, como recoge CSO Online, sin ASLR el riesgo de ejecución de código aumenta mucho.
6. Vigila los reinicios de los workers: líneas repetidas como «worker process … exited on signal» en el error log de NGINX pueden indicar intentos de explotación. Ejecuta los workers con un usuario sin privilegios y separa la red del proxy inverso de los sistemas internos más críticos.

Cómo ayuda ARXDOME

El inventario de ARX Sentry enumera software, procesos y puertos de cada servidor con el agente, así encuentras dónde se ejecuta NGINX. ARX Shield muestra las vulnerabilidades abiertas por máquina y por paquete, y ARX Expose qué servicios públicos de tu empresa tienen vulnerabilidades conocidas: juntos te ayudan a decidir por qué servidores empezar.

Última actualización: 20 de octubre de 2026