Productos FTTH

Tienda FFTH desde 2004

Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Vulnerabilidad de 15 años en NGINX permite ejecutar código remoto y colapsar procesos


Se ha revelado una vulnerabilidad denominada CVE-2026-42533 que afecta al motor de scripts de nginx. Este fallo ha estado presente desde marzo de 2011, debido a la implementación del soporte de regex en la directiva map. El problema, reportado por el investigador Stan Shaw, podría permitir que los atacantes provocen la caída de los procesos trabajadores y logren la ejecución remota de código. Para solucionar este error, se han lanzado actualizaciones en las versiones 1.30.4 (estable) y 1.31.3 (mainline), además de parches para NGINX Plus.





Un fallo recientemente revelado, rastreado como CVE-2026-42533, afecta al motor de scripts de nginx y ha sido explotable silenciosamente desde marzo de 2011, cuando la directiva map obtuvo soporte para expresiones regulares (regex).

El investigador de seguridad Stan Shaw informó del error al F5 SIRT, que coordinó una corrección lanzada en nginx 1.30.4 (estable) y 1.31.3 (mainline), junto con los parches correspondientes para NGINX Plus R33–R36 (corregido en R36 P7) y 37.0.0.1–37.0.2.1 (corregido en 37.0.3.1).

La vulnerabilidad es un fallo de ejecución remota de código (RCE) previo a la autenticación, originado por la falta de guardado/restauración del estado de captura de PCRE en el motor de scripts interno de nginx.

nginx evalúa las expresiones en dos pasadas: una pasada LEN para medir el tamaño del búfer y una pasada VALUE para escribir los datos reales; ambas dependen de un array compartido y mutable llamado r->captures. Cuando una directiva map con un patrón regex se ejecuta entre dos referencias a un grupo de captura (como $1), sobrescribe silenciosamente ese estado compartido, provocando que las pasadas LEN y VALUE no coincidan en el tamaño.

Vulnerabilidad de NGINX de 15 años

Este desajuste produce dos primitivas de ataque distintas:

  • Desbordamiento de búfer de heap (Heap buffer overflow): cuando la captura sobrescrita es más grande que la original, la pasada VALUE escribe más datos de los que el búfer tenía asignados, corrompiendo la memoria adyacente del heap con contenido totalmente controlado por el atacante.
  • Fuga de información (Information leak): cuando la captura sobrescrita es más pequeña, el búfer es demasiado grande y la respuesta filtra bytes del heap no inicializados —incluyendo punteros de libc y del heap suficientes para derrotar ASLR en una sola solicitud GET no autenticada.

Al encadenar estas dos primitivas, un atacante puede lograr una RCE fiable utilizando aproximadamente una solicitud de fuga, unas 40 conexiones de spray y una solicitud que active el desbordamiento, reportada con una fiabilidad de 10/10 en Ubuntu 24.04 con ASLR totalmente habilitado.

Según el informe de Cyberstan, el error no se limita a una sola directiva. Abarca al menos 13 sitios de llamada independientes en 9 archivos fuente, afectando tanto a los módulos HTTP como a los de stream. Cualquier configuración que combine una fuente de captura regex (bloques location, server_name, rewrite o if) con una variable map basada en regex evaluada posteriormente en el mismo contexto de solicitud es potencialmente explotable, incluso a través de directivas separadas en el mismo bloque de localización.

Las directivas comúnmente afectadas incluyen:

  • proxy_set_header, proxy_method, proxy_pass, fastcgi_param, uwsgi_param, scgi_param
  • grpc_set_header, return, add_header, rewrite, set
  • root, alias, access_log y varias otras

Existe una variante separada e independientemente explotable a través de grupos de captura con nombre ((?P<name>...)), que se almacenan en caché de forma diferente y no se solucionarían con un parche que solo aborde las capturas numeradas.

Versiones Afectadas

ProductoVersiones AfectadasVersión Corregida
NGINX Open Source (estable)0.9.6 hasta 1.30.31.30.4
NGINX Open Source (mainline)hasta 1.31.21.31.3
NGINX PlusR33–R36R36 P7
NGINX Plus (línea nueva)37.0.0.1–37.0.2.137.0.3.1

Cabe destacar que las correcciones recientes para otros errores de nginx —CVE-2026-42945, CVE-2026-9256, CVE-2026-42055 y CVE-2026-48142— no abordan este problema, lo que significa que las organizaciones que aplicaron parches para esos fallos siguen expuestas.

Sorprendentemente, este comportamiento exacto fue señalado por primera vez hace más de una década en un ticket de trac de nginx de 2014, donde el desarrollador Maxim Dounin lo reconoció como un defecto, pero nunca fue remediado completamente como un problema crítico de seguridad.

El investigador ha publicado un escáner de configuración estática en GitHub (0xCyberstan/CVE-2026-42533-Config-Scanner) que identifica órdenes de directivas vulnerables sin explotar nada, brindando a los defensores una forma de auditar la exposición inmediatamente.

La prueba de concepto completa y el análisis de explotación se mantienen reservados durante 21 días después del parche para dar tiempo a los administradores a actualizar, una decisión basada en la rápida creación de armas vista después de que CVE-2026-42945 (“NGINX Rift”) se hiciera público.

Recomendaciones Tácticas de Seguridad

  • Actualiza inmediatamente a nginx 1.30.4, 1.31.3 o la versión parcheada correspondiente de NGINX Plus.
  • Ejecuta el escáner estático contra tus configuraciones de producción para identificar órdenes de directivas vulnerables.
  • Audita cualquier bloque de localización que combine capturas regex con variables map basadas en regex, y reestructura las configuraciones para evitar que las referencias de captura aparezcan antes o después de la evaluación de la variable map.
  • Trata esto como urgente incluso si no utilizas HTTP/3 u otros módulos parcheados recientemente, ya que este fallo es independiente de esas correcciones.


Fuentes:
https://cybersecuritynews.com/15-year-old-nginx-vulnerability/

0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.