Ah, NGINX. El confiable servidor web que ha estado impulsando silenciosamente internet como ese amigo confiable que siempre aparece con pizza... hasta que un día accidentalmente inunda tu cocina con código malicioso porque alguien susurró el nombre de variable equivocado. Damas y caballeros, bienvenidos a CVE-2026-8711, el último episodio de la interminable telenovela titulada "¿Cómo permitimos que los clientes controlen las cosas otra vez?". En esta emocionante entrega, atacantes remotos no autenticados pueden provocar un desbordamiento de búfer basado en el montón en el módulo JavaScript de NGINX (njs). Sí, leyeron bien. Su sofisticado proxy inverso que se supone que lo protege todo ahora es vulnerable a un clásico momento de "ups, desbordé el montón" que puede llevar a deliciosos fallos de denegación de servicio y, en sistemas mal configurados (los estoy mirando a ustedes, los que odian ASLR), ejecución remota completa de código en el proceso de trabajo.
Imagínate esto: Un administrador bienintencionado habilita js_fetch_proxy con variables controladas por el cliente. Ya sabes, cositas inocentes como $http_x_user o $http_x_password. Porque nada dice "seguro" como dejar que desconocidos de internet ayuden a construir tus URL de proxy. Luego lo conectan a una función NJS que llama a ngx.fetch(). ¡Boom! Es como darle un lanzallamas a un niño pequeño y decirle: "Solo no lo apuntes a las cortinas". Un atacante crea una solicitud HTTP especial, y de repente el trabajador de NGINX tiene un día muy malo: la memoria del montón se corrompe, el proceso se bloquea, se reinicia, se bloquea de nuevo... Es el equivalente digital de ese amigo que sigue actualizando la página "accidentalmente" durante tu importante videollamada de Zoom. Ataque DoS logrado con estilo.
¿Y si ASLR está desactivado o mal configurado? ¡Enhorabuena! Podrías ganar el gran premio: la ejecución de código arbitrario. Porque, ¿para qué conformarse con servidores que se bloquean cuando puedes infectarlos con malware?
CVE: CVE-2026-8711 (suena como una habitación de hotel de lujo donde el minibar está lleno de exploits)
CWE: 122 – Desbordamiento de búfer basado en montón (el caso especial de "no volví a comprobar el tamaño")
Versiones afectadas: njs versiones 0.9.4 a 0.9.8
Corregido en: njs 0.9.9 (sí, finalmente contaron hasta 9 correctamente).
F5, los orgullosos creadores de NGINX, confirmaron que la vulnerabilidad se limita al plano de datos. El plano de control está a salvo, probablemente sentado en un rincón tomando café y juzgando a todos. Otros productos importantes de F5, como BIG-IP, aparentemente no están incluidos en esta vulnerabilidad.
NGINX es famoso por ser ligero, rápido y estable. Sin embargo, aquí estamos en 2026, descubriendo que mezclar JavaScript, variables controladas por el cliente y proxies es como mezclar Red Bull, tequila y malas decisiones. ¿Quién iba a predecir que dejar que extraños influyeran en las llamadas a `fetch()` acabaría mal? Es casi como si los servidores web olvidaran la regla de oro: nunca confíes en el cliente. Ni un poquito. Ni siquiera si te piden "por favor, por favor, con $http_x_hax encima".
¿Qué deberías hacer? (Además de reír/llorar)
Actualiza inmediatamente a NGINX JavaScript 0.9.9 o posterior. Sí, ahora mismo. Deja de lado el meme y actualiza.
Si no puedes actualizar (por algún motivo), revisa tus configuraciones de js_fetch_proxy con variables de cliente. Refactoriza o elimina esos patrones antes de que alguien refactorice toda tu infraestructura.
Habilita ASLR correctamente. Estamos en 2026, gente. Dejen de vivir como si fuera 1999.
En resumen, otro día, otro desbordamiento de búfer que nos recuerda que el software no es más que una forma elegante de decir "un montón de vulnerabilidades esperando ser explotadas". NGINX sigue siendo genial... cuando no está ocupado arrasando con la memoria hasta el olvido. Manténganse actualizados, amigos. Y tal vez dejen de permitir que encabezados aleatorios construyan sus URL. Eso no es "dinámico", es "propiedad dinámica".
