NGINX 1.30.6 y njs 1.0.2: comprueba qué parche está cargado
Guía defensiva para inventariar NGINX, distinguir stable de mainline y comprobar njs por separado después de los avisos de octubre de 2026, sin probar exploits en producción.
31 de octubre de 2026 · Leopoldo Benavente Cadena · 6 min de lectura
Actualizar NGINX después de un aviso de seguridad parece una operación de una línea, pero el número que muestra un binario no siempre describe el paquete que distribuye tu proveedor ni los módulos dinámicos que carga la configuración. El aviso oficial del 14 de octubre de 2026 separa dos carriles: 1.30.6 como stable y 1.31.7 como mainline, ambos con cinco correcciones. El 21 de octubre apareció 1.31.8, que es la mainline que figura actualmente en la página de descargas.
El mismo anuncio publicó njs 1.0.2 para dos problemas distintos. Por eso conviene tratar la revisión como un inventario de componentes, no como una comparación ciega de versiones.
Qué significan los números
| Componente | Referencia oficial al 31 de octubre | Qué permite afirmar | Qué no permite afirmar |
|---|---|---|---|
| NGINX stable | 1.30.6 |
Es el stable upstream y el umbral que el advisory marca como no vulnerable para los cinco CVE de octubre | Que tu paquete de Linux, imagen o sus backports tenga exactamente ese número |
| NGINX mainline | 1.31.8 en descargas; 1.31.7+ en el advisory |
1.31.7 es el mínimo mainline corregido para esos cinco avisos; 1.31.8 es la versión mainline vigente |
Que 1.31.8 añada una corrección de seguridad que el advisory no describa |
| njs | 1.0.2 |
Corrige el rango afectado 0.7.10–1.0.1 para dos problemas de XML |
Que actualizar NGINX actualice automáticamente el paquete nginx-module-njs |
Stable y mainline son etiquetas del sitio upstream, no sinónimos de “seguro” y “peligroso”. Una distribución, imagen empresarial o proveedor cloud puede aplicar un backport y conservar un número upstream anterior. La evidencia válida para ese caso es el changelog o advisory del proveedor, junto con el identificador exacto del paquete o imagen.
Los cinco avisos de NGINX tienen condiciones concretas: alias junto con rewrite, evaluación de expresiones de cadena con variables, HTTP/3, rotación de claves de tickets TLS y ngx_http_ssi_module con AIO. El advisory marca como no vulnerables 1.30.6+ y 1.31.7+, pero no convierte toda versión anterior en una prueba de explotación. La exposición depende de los módulos, directivas y protocolos realmente habilitados.
Inventario sin tocar el servicio
Haz la primera revisión sobre el mismo binario, contenedor o VM que luego compararás con el paquete del proveedor. En un laboratorio, guarda la salida como evidencia privada:
nginx -v
nginx -V 2>&1-v imprime la versión y -V añade la versión del compilador y los argumentos de configuración. Es información útil para saber si el binario fue compilado con un módulo estático o con opciones especiales, pero no es una auditoría de módulos dinámicos cargados desde la configuración. Tampoco prueba un backport.
Revisa de forma acotada el archivo de configuración que has copiado al laboratorio, sin volcarlo en un ticket público ni pegar secretos:
grep -nE '^[[:space:]]*load_module|^[[:space:]]*js_import|http3|ssl_session_ticket_key|aio|ssi|alias|rewrite' nginx.confEl filtro solo orienta la revisión. Un resultado positivo indica una condición que merece comparar con el advisory; no demuestra por sí mismo que el proceso la use, que la ruta sea accesible o que exista explotación. Si la instalación usa includes, inspecciona esos archivos de laboratorio de forma equivalente.
njs se comprueba aparte
njs no es Node.js ni una versión alternativa de NGINX. Es un módulo que NGINX invoca en puntos de integración definidos. En Linux, la documentación upstream describe el paquete nginx-module-njs y el uso de load_module para cargar, por ejemplo, ngx_http_js_module.so o ngx_stream_js_module.so.
La página de seguridad de njs marca como no vulnerable 1.0.2+ para CVE-2026-101025 (fuga de memoria al analizar XML malformado) y CVE-2026-101019 (valores inconsistentes de atributos XML que podían afectar la validación XML firmada). Si no hay una directiva js_import en la configuración, la propia página de seguridad indica que el proceso no queda expuesto a vulnerabilidades relacionadas con JavaScript; aun así, hay que documentar el alcance real del paquete.
Comprueba la procedencia del módulo con el gestor de paquetes de tu distribución o con el manifiesto de la imagen, y relaciona ese dato con la versión 1.0.2 que requiere el advisory. No infieras la versión de njs desde nginx -v. Un módulo compilado desde fuentes, un paquete nginx-module-njs y un artefacto del proveedor pueden tener calendarios diferentes.
La documentación actual también indica que el motor njs integrado está deprecated desde 1.0.0 y recomienda QuickJS para nuevas configuraciones. Eso no convierte por sí solo una instalación existente en incorrecta: primero identifica el motor, el módulo y el contrato que usa tu configuración.
Validar una configuración en el laboratorio
nginx -t comprueba la sintaxis y trata de abrir los archivos referidos por la configuración. Copia una configuración mínima a un contenedor o VM sin tráfico real y ejecuta:
nginx -t -c "$PWD/nginx.conf"El -c evita depender del archivo por defecto. La prueba puede fallar por rutas, permisos, certificados o módulos ausentes; ese error es información para corregir el entorno de laboratorio, no una razón para desactivar controles en producción. La documentación distingue -t de -T: este último además vuelca la configuración, así que no lo uses para adjuntar salidas sin revisar secretos.
Antes de evaluar un cambio, registra el identificador de la imagen o paquete, la salida de nginx -V, los módulos que aparecen en load_module, el resultado de nginx -t y las directivas que condicionan los cinco avisos. Si el cambio altera HTTP/3, tickets TLS, AIO, SSI, alias/rewrite o expresiones, añade pruebas funcionales de tu servicio en staging. No hace falta fabricar una entrada XML malformada, un cuerpo HTTP/3 ni una rotación de claves para este inventario.
Cómo cerrar la actualización
- Clasifica el carril elegido: stable upstream
1.30.6, mainline1.31.8o un paquete de proveedor con backports documentados. No cambies de stable a mainline automáticamente solo por un aviso. - Confirma el artefacto que se desplegaría y su firma o digest según el canal de distribución. El número upstream es una pista, no la identidad completa del artefacto.
- Revisa njs como dependencia separada. Si la configuración carga
ngx_http_js_module.soongx_stream_js_module.so, confirma la versión y el origen de ese módulo antes de declarar cerrada la corrección. - Ejecuta
nginx -ten el entorno aislado y conserva el plan de reversión del paquete, imagen y configuración. - Programa la ventana operativa con el responsable del servicio. Esta guía no recomienda
reload, reinicio ni despliegue sobre un servidor productivo.
El resultado que buscas no es una frase como “NGINX está parcheado”, sino una evidencia trazable: binario identificado, canal elegido, backport del proveedor comprobado, módulos separados y configuración validada en un entorno controlado. Esa distinción evita que una salida correcta de nginx -v oculte un módulo njs antiguo o un artefacto distinto al que revisaste.
Comentarios