TL; DRTras descubrir el tercer desbordamiento de búfer en 2026 (y, según F5, una vulnerabilidad de ejecución remota de código si no hay ASLR) mientras trabajaba con expresiones regulares y variables, el desarrollador de freenginx, Maxim Dunin, decidió que era hora de ponerle fin y añadió una comprobación del tamaño de las variables a su producto antes de escribir datos en él. Desde entonces, Nginx ha copiado esta característica, lo que da esperanzas de que se eliminen las nuevas vulnerabilidades de seguridad relacionadas con este problema.
Ahora, los detalles.
El 19 de junio se hizo comprometerse En Freenginx, se añade un campo `end` al descriptor de la variable, que indica el final del búfer. Anteriormente, solo existía un puntero a su inicio (`pos`), la longitud requerida se calculaba (y aún se calcula) por adelantado, y para cuando los datos se copiaban a la variable, se asumía que la longitud calculada correctamente garantizaría que los datos cabrían en el búfer. Desafortunadamente, esto ya ha demostrado ser incorrecto dos veces en mayo de 2026 debido a varios descuidos.1 (linux.org.ru), 2 (linux.org.ru)), lo que provocó desbordamientos de búfer y consecuencias nefastas. Ahora, cuando se crea el búfer de una variable, también se llena el puntero a su final, y antes de escribir datos en la variable, si los datos no caben, el procesamiento de la solicitud terminará con un error de manera controlada. Esto significa que los errores de cálculo de longitud aún pueden persistir, pero no desperdiciarán memoria; solo harán que falle la solicitud HTTP específica. Las siguientes confirmaciones (2 (freenginx.org), 3 (freenginx.org)Se añadió una protección similar a otras partes del código, incluido el código de registro de acceso. Se publicó una versión el 7 de julio. Freenginx 1.31.3, que incluye esta corrección.
El 15 de julio, nginx detectó estas confirmaciones (1 (github.com), 2 (github.com), 3 (github.com), por alguna razón intercambiando el segundo y el tercero en la cadena), el problema fue asignado CVE-2026-42533y F5 publicó un comunicado oficial SA (f5.com).
Respecto a la vulnerabilidad específica en esta ocasión: se manifiesta al usar la directiva map con regexps con parámetros extraídos. En cuanto a las demás condiciones necesarias para que se active, el texto en la descripción del commit y el texto en el SA difieren ligeramente: el SA indica que se debe calcular una cadena determinada a continuación, que utiliza el parámetro extraído restante del map, antes del resultado de ese mismo map. En la descripción del commit del ejemplo, entre estos pasos, la variable que contiene el parámetro extraído también se pone a cero. Sea como fuere, es poco probable que esto ocurra en la mayoría de los nginx en ejecución y, por lo tanto, la vulnerabilidad afectó a pocas personas. También vale la pena señalar que no hay una solución para el cálculo de la longitud específicamente para este caso en las ediciones confirmadas (¿o busqué mal?), solo hay una protección que convierte el problema en un fallo controlado de la solicitud HTTP. Aunque se añadieron algunas correcciones a freenginx el 19 de julio (5bfb, 7622, b906) calculando la longitud para una situación similar, pero no está inmediatamente claro si este es el caso o no.
La vulnerabilidad apareció en la versión nginx 0.9.6; las correcciones se incluyeron en las versiones freenginx 1.31.3, nginx 1.30.4 y nginx 1.31.3.
El equipo de soporte de nginx agradece a varias personas por haber informado de forma independiente sobre la vulnerabilidad y por haber seguido los "estándares de divulgación coordinada":
F5 reconoce a Ming Xuan, DKD (@pidifn), Ji'an Zhou y Zhen Yan de AntAISecurityLab, Rafael Gacek, Sergii Negodiuk de EVO.company, Lam Jun Rong de Calif.io, Mufeed VH de Winfunc Research (winfunc.com), Vexera AI (https://vexera.ai), Tu Tran Dinh (@1w4y), Stan Shaw (cyberstan), qianshuidewajueji, zenneth (randomguy6407), Zhenpeng (Leo) Lin de depthfirst, Lukas Johannes Moeller, Melih Tolga Sahin de Vodafone Türkiye, Ayoub Nabil Boubagrat (GitHub: @ayoubnabil) y Milan Jovic (Kljunowsky) por llamar nuestra atención sobre este problema de forma independiente y seguir los más altos estándares de divulgación coordinada.
En freenginx, la información que acompaña a la corrección se limita en realidad al mensaje de confirmación. cambiosEsta corrección ni siquiera está etiquetada como "seguridad" o "corrección de errores", sino simplemente como "funcionalidad". Al parecer, el autor no consideró este problema crítico. Es imposible determinar la relación entre los problemas reportados por las personas mencionadas en F5 y la confirmación copiada de freenginx, o si ellos (o cualquier otra persona) reportaron el problema al autor de freenginx.
Fuente: linux.org.ru
