Un parche del 15 de julio para código escrito en 2011

El 15 de julio de 2026 el proyecto nginx publicó las versiones 1.30.4 y 1.31.3, y esa entrega cerró un desbordamiento de montículo que era alcanzable en todas las versiones desde la 0.9.6. Esa versión es de 2011. La vulnerabilidad se registra como CVE-2026-42533 y puntúa 9,2 en la escala CVSS versión 4.0. F5 publicó el aviso K000162097 para clientes de NGINX Plus, corregido en 37.0.3.1.

La lista de quienes lo notificaron es inusual. Más de una docena de investigadores comunicaron el mismo problema de forma independiente, entre ellos Mufeed VH de Winfunc Research, y el mantenedor veterano Maxim Dounin se encargó de la corrección. Cuando tanta gente encuentra un fallo a la vez, lo razonable es suponer que no era difícil de encontrar y que otros lo hallaron sin presentar ningún informe.

Qué debe haber en su configuración para que importe

El error vive en el motor de scripts, que evalúa las expresiones de cadena que nginx construye en el momento de cada petición. Esa evaluación se hace en dos pasadas. La primera mide el tamaño necesario del búfer usando el estado de captura de ese instante. La segunda escribe en ese búfer con datos de captura en los que la petición puede influir. Cuando ambas pasadas discrepan, la escritura es mayor que el espacio reservado.

El desencadenante es más estrecho de lo que sugiere el rango de versiones. Requiere una directiva map basada en expresiones regulares cuya variable de salida se referencie en una expresión de cadena tras una captura de una coincidencia previa, las capturas numeradas escritas como dólar-uno y dólar-dos. Si su configuración no contiene un mapa de esa forma, el número de versión por sí solo no le coloca en el conjunto afectado. Ese es el dato más útil de toda la divulgación.

Sin autenticación, pero todavía sin arma

Donde el patrón está presente, la petición que lo activa no necesita credenciales. Basta una petición HTTP manipulada desde cualquier punto de internet. El resultado fiable es el fallo y reinicio de un proceso de trabajo, es decir, una denegación de servicio en la puerta de entrada de lo que el servidor publica. La ejecución remota de código es el caso más difícil, disponible donde la aleatorización del espacio de direcciones está desactivada o puede sortearse, y el investigador Stan Shaw sostiene que el fallo aporta su propia vía para rodear esa protección.

A 20 de julio no hay código de explotación público y la CVE no figura en el catálogo estadounidense de vulnerabilidades explotadas conocidas. Ese es el estado actual, no un pronóstico. Shaw ha dicho que publicará una prueba de concepto 21 días después de la salida del parche, lo que la sitúa en la primera semana de agosto. Una vulnerabilidad crítica sin explotar pero con fecha publicada es un problema de planificación distinto de una sin fecha.

Tres desbordamientos en un subsistema en dos meses

CVE-2026-42533 no es un hallazgo aislado. Es el tercer desbordamiento de montículo divulgado en el código de evaluación de expresiones de nginx en unos dos meses, tras CVE-2026-42945 en mayo y CVE-2026-9256 poco después. Tres hallazgos en un subsistema en un trimestre son un patrón y no una casualidad, y el patrón indica que el diseño de dos pasadas está siendo repasado por gente que ya sabe dónde mirar.

La consecuencia para la planificación es clara. Quien trate esto como un simple salto de versión y lo dé por cerrado tiene una probabilidad apreciable de volver aquí dentro del mismo trimestre. En la lista de vigilancia va el subsistema, no el número de CVE, y lo que se puede reducir de forma permanente son las formas de configuración que llegan hasta él.

La comprobación previa a llamar a su proveedor

La mayoría de las divulgaciones críticas de servidores web dejan al empresario dependiendo de otros. Esta no, porque el desencadenante es legible en un archivo que usted puede abrir. Pida su versión de nginx y pregunte después si algún bloque map de la configuración usa una expresión regular y alimenta una variable que más tarde se combina en una cadena junto a capturas numeradas. Dos preguntas, una respuesta, y ya sabe si principios de agosto es un plazo o una nota.

Para las empresas dentro del alcance de la Directiva sobre seguridad de las redes y sistemas de información en la Unión Europea, y para quienes siguen la guía equivalente del Reino Unido, la documentación importa tanto como el parche. Registre en qué versión estaba, la fecha en que revisó la configuración y la mitigación aplicada. Un regulador que pregunte por una vulnerabilidad crítica publicada en julio querrá la fecha en que la evaluó, no solo la fecha en que finalmente actualizó.

Leer a continuación: Cuatro agentes de código escaparon sin forzar nada  |  ServiceNow parcheó su nube primero y a usted 103 días más tarde