TL;DR: Al enfrentarse a la tercera sobrecarga de búfer detectada en 2026 (y, según F5, RCE si no hay ASLR) al trabajar con expresiones regulares y variables, el desarrollador de freenginx, Maxim Dunin, decidió que era hora de poner fin a esto, y añadió a su producto una verificación del tamaño de la variable antes de escribir datos en ella. Desde ahí, esta novedad fue llevada a nginx, lo que da esperanza de que se detengan nuevas CVE sobre este tema.
Ahora los detalles.
El 19 de junio se realizó un commit en freenginx, que añade en el descriptor de variable un campo end, que indica el final del búfer. Anteriormente, solo había un puntero a su inicio (pos), la longitud necesaria se calculaba (y todavía se calcula) de antemano, y en el momento de copiar datos en la variable se asumía que la longitud calculada correctamente anteriormente garantizaba que los datos encajaran en el búfer. Desafortunadamente, ya dos veces en mayo de 2026, debido a diversas negligencias, esto resultó no ser así (1 (linux.org.ru), 2 (linux.org.ru)), lo que llevó a desbordamientos de búfer y malas consecuencias. Así que ahora, al crear un búfer de variable, también se llena el puntero a su final, y antes de escribir en la variable datos, si los datos no caben, el procesamiento de la solicitud se cerrará controladamente con un error. Es decir, los errores en el cálculo de longitud pueden seguir existiendo, pero ahora no afectarán la memoria, sino que solo fallará una solicitud http específica. Con los siguientes commits (2 (freenginx.org), 3 (freenginx.org)) se añadió una protección similar en otros lugares del código, incluyendo el código de gestión del access-log. El 7 de julio se publicó la versión freenginx 1.31.3, que incluye esta corrección.
El 15 de julio, estos commits fueron tomados por nginx (1 (github.com), 2 (github.com), 3 (github.com), cambiando curiosamente el segundo y el tercero en la cadena), el problema fue asignado CVE-2026-42533, y F5 lanzó un SA (f5.com).
Con respecto a la vulnerabilidad específica esta vez: se manifiesta al utilizar la directiva map con expresiones regulares que tienen parámetros destacados. En cuanto a las otras condiciones necesarias para que ocurra, el texto en la descripción del commit y el texto en SA difieren un poco: en SA se indica que posteriormente debe calcularse una cierta cadena que utiliza el parámetro destacado, que queda del map, antes que el resultado de ese mismo map. En la descripción del commit, en el ejemplo entre estos pasos, también participa la puesta a cero de la variable que contiene el parámetro destacado. De todos modos, en la mayoría de los nginx en funcionamiento, probablemente no se encuentre algo así, y la vulnerabilidad de este modo ha afectado a pocos. También cabe destacar que las correcciones al cálculo de la longitud en este caso específico parecen no estar en las modificaciones commitadas (¿o busqué mal?), solo hay una protección que transforma el problema en un fallo http controlado. Sin embargo, el 19 de julio se añadieron algunas correcciones en freenginx (5bfb, 7622, b906) al cálculo de la longitud para una situación similar, pero no se puede entender a primera vista si es eso o no.
La vulnerabilidad apareció en la versión nginx 0.9.6, las correcciones llegaron a las versiones freenginx 1.31.3, nginx 1.30.4, nginx 1.31.3.
En SA de nginx se agradece a varias personas por los informes independientes sobre la vulnerabilidad y por cumplir con los "estándares de divulgación coordinada":
F5 agradece 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 informar de manera independiente sobre este problema y por 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 esencialmente al mensaje durante el commit. En changelog- esta corrección ni siquiera está marcada con la etiqueta "seguridad" (security) ni "corrección" (bugfix), solo "adición" (feature). Probablemente, el autor no consideró que este problema fuera crítico. No se ha podido averiguar cómo se relacionan los informes sobre el problema de las personas mencionadas en F5 y el commit tomado de freenginx, si ellos (o alguien más) informaron al autor de freenginx sobre el problema.
Fuente: linux.org.ru
