El 14 de octubre de 2026, nginx publicó la versión 1.31.7 y, con ella, cinco avisos de seguridad de golpe. Al día siguiente, los titulares hablaban de vulnerabilidades críticas y de explotación activa.
Si llevas una empresa y has leído alguno de esos titulares, probablemente te hiciste una pregunta muy razonable: ¿y esto me afecta a mí?
La respuesta honesta es: puede que no. Y si te afecta, puede que no sea urgente. Pero para saberlo hay que entender dos cosas que ningún titular cuenta.
Este artículo no va a repetir lo que ya puedes leer en diez sitios. Va a responder lo que de verdad necesitas: por qué esto te afecta aunque tú no toques servidores, y cómo saber en diez minutos si te toca a ti.
Qué es nginx y por qué te afecta aunque no sepas que lo tienes
nginx es el programa que atiende las peticiones que llegan de internet a tu web. Cuando alguien escribe tu dominio en el navegador, lo primero que responde no es tu web: es nginx.
Y aquí está lo que más cuesta de entender, igual que pasaba con PHP2Shell: el fallo no está en tu web, está en la pieza que la sirve.
Esa distinción tiene una consecuencia muy concreta:
- No lo arregla ningún plugin de seguridad.
- No lo arregla tener la web actualizada.
- No importa lo bien hecha que esté.
El atacante no necesita llegar a tu web. Le basta con llamar a la puerta.
Y lo tienes aunque no lo sepas. Si tu web está en un hosting, hay un nginx delante. Si tienes un servidor propio, casi seguro que lo lleva nginx. Si usas un panel de control, lo instaló él por ti hace años.
Un detalle que dice mucho
De los cinco fallos, uno arrastra desde la versión 0.1.29.
Eso es nginx del año 2008.
No es un fallo nuevo: es un fallo viejo que alguien ha encontrado ahora, y que lleva dieciocho años en el código que sirve buena parte de internet. Lo cuento porque explica algo importante — que una pieza lleve años funcionando sin problemas no significa que esté revisada.
El matiz que no cabe en un titular
Aquí está lo que de verdad necesitas saber, y lo que casi nadie dice:
Tener una versión vulnerable no significa estar expuesto.
Los cinco fallos no afectan a todo nginx. Afectan a funciones concretas: una forma determinada de servir carpetas, una opción de rendimiento, una versión nueva del protocolo. Si tu servidor no usa ninguna de ellas, el riesgo real para ti es muy distinto del que sugiere el titular.
Esto funciona en las dos direcciones, y por eso importa:
- Puedes estar tranquilo aunque tu versión salga en la lista, si no usas esas funciones.
- Puedes estar en riesgo serio con un fallo etiquetado como «medio», si lo usas en producción y está expuesto a internet.
La pregunta útil, entonces, no es «¿qué nota tiene este CVE?». Es:
¿Uso yo esa función, y está expuesta?
Y esa no la responde ninguna lista de vulnerabilidades. La responde alguien que conozca tu instalación.
Por qué nginx dice «media» y los periódicos dicen «crítica»
Si buscas estos CVE te vas a encontrar con una contradicción desconcertante, y conviene entenderla porque lleva a decisiones malas en las dos direcciones.
nginx clasifica los cinco como gravedad media. Está escrito en su página oficial de avisos.
Varios medios los han titulado como críticos y hablan de explotación activa: BleepingComputer y SecurityWeek. INCIBE también publicó aviso.
¿Quién tiene razón? Los dos. Y la explicación es sencilla:
Una puntuación de gravedad mide el fallo en abstracto. No sabe si tú usas alias, si tienes HTTP/3 o si tu nginx está detrás de un balanceador que filtra la mitad de las peticiones.
Hay otra razón, más prosaica: F5 vende productos comerciales basados en nginx (NGINX Plus, NGINX App Protect) y sus avisos y los del nginx libre no siempre cubren lo mismo ni se puntúan igual. Buena parte de la confusión viene de mezclar unos con otros.
👉 La gravedad publicada sirve para priorizar, no para decidir. Lo que decide es: ¿uso yo esa función y está expuesta a internet?
Cómo saber si te afecta, en diez minutos
Ahora sí, la parte práctica. Va de menos a más técnica: empieza por la primera que puedas hacer y para cuando tengas la respuesta.
Si tu web está en un hosting compartido
No lo gestionas tú — nginx lo lleva tu proveedor y no puedes actualizarlo. Ve directo al apartado «Qué preguntarle a tu proveedor», que es tu vía.
Desde fuera, sin tocar nada
Desde cualquier ordenador con terminal:
curl -sI https://tudominio.com | grep -i serverSi responde Server: nginx/1.30.2, ya tienes la versión. Y de paso un problema añadido: estás anunciando al mundo cuál usas. Eso se quita.
Si responde solo Server: nginx sin número, alguien tuvo el buen criterio de ocultarlo. Y si no aparece nginx por ningún lado, puede que estés detrás de Cloudflare: el nginx sigue ahí, solo que no se ve desde fuera.
Si tienes servidor propio o VPS
nginx -vResponde algo así:
nginx version: nginx/1.30.2Y compara con esto:
| Rama | Versión segura |
|---|---|
| Mainline | 1.31.7 o superior |
| Stable | 1.30.6 o superior |
💡 ¿Mainline o stable? nginx mantiene dos ramas a la vez: la mainline (1.31.x) lleva las novedades, la stable (1.30.x) solo correcciones. Las dos reciben los parches. No pasa nada por estar en la stable — lo que pasa es estar por debajo de la corregida.
⚠️ Ojo: nginx -v (minúscula) da la versión. nginx -V (mayúscula) da además con qué módulos se compiló, que hace falta para el siguiente paso.
⚠️ Y si instalaste nginx desde los repositorios de tu distribución y no desde los de nginx, el número puede no coincidir con los de aquí: las distribuciones aplican los parches sin cambiar el número. En ese caso manda el changelog de tu paquete.
Y lo que de verdad decide: ¿usas alguna función afectada?
Esto es lo que separa «tengo que actualizar hoy» de «actualizo cuando toque». Un comando por fallo:
| Fallo | Qué afecta | Compruébalo con |
|---|---|---|
| CVE-2026-15176 | alias con rewrite (desde 2008) | grep -rn "alias" /etc/nginx/ |
| CVE-2026-97205 | AIO (hay que activarlo a propósito) | grep -rn "aio" /etc/nginx/ |
| CVE-2026-95101 | HTTP/3 (muchos no lo tienen) | nginx -V 2>&1 | grep http_v3 |
| CVE-2026-97629 | tickets TLS | grep -rn "ssl_session_tickets" /etc/nginx/ |
| CVE-2026-93479 | evaluación de scripts (desde 1.30.0) | — |
🔑 Dos avisos sobre esa tabla:
- La directiva
aliases muy común en configuraciones hechas a mano para servir/static/,/uploads/o documentación. Si tienes nginx configurado por alguien, es probable que esté. - Los tickets de sesión TLS vienen activados por defecto: si el
grepno devuelve nada, es que los tienes. Lo que permite el fallo es que alguien reutilice una sesión cifrada que no le pertenece — en una web con usuarios identificados, eso importa.
Si no te manejas con la terminal
No pasa nada: salta al apartado siguiente y pregúntaselo a quien te lleva el servidor. Esa conversación te va a dar más información que cualquier comando.
Qué hacer si no puedes actualizar ahora
Actualizar nginx suele ser sencillo, pero no siempre se puede: una configuración delicada, un módulo compilado a medida, una ventana de parada que no cabe esta semana.
Tres de los cinco fallos se pueden evitar sin actualizar, si no necesitas esa función:
| Fallo | Mitigación | Coste |
|---|---|---|
| AIO | quitar aio on; | Ninguno si no lo usabas |
| HTTP/3 | desactivar quic/http3 | Los clientes caen a HTTP/2. Imperceptible |
| Tickets TLS | ssl_session_tickets off; | Reconexiones algo más lentas |
⚠️ Con honestidad: esto no son arreglos, son parches. Los fallos de alias y de evaluación de scripts no tienen mitigación limpia. Si los usas, la única solución real es actualizar.
Y una advertencia práctica: revisa tu configuración antes de tocar nada. Desactivar algo que sí usabas deja el servicio roto, y eso es peor que el CVE.
Cómo actualizar, según cómo lo instalaste
# Debian / Ubuntu con el repositorio oficial de nginx
sudo apt update && sudo apt install --only-upgrade nginx
# RHEL / Rocky / Alma
sudo dnf update nginx
# Comprobar la configuración ANTES de recargar
sudo nginx -t
# Recargar sin cortar las conexiones en curso
sudo systemctl reload nginx🔑 nginx -t antes de recargar, siempre. Es un segundo y es la diferencia entre una recarga limpia y una web caída.
⚠️ Si instalaste nginx desde los repositorios de tu distribución y no desde los de nginx, es posible que el número de versión no coincida con los de este artículo: las distribuciones aplican los parches sin cambiar el número. En ese caso lo que manda es el changelog de tu paquete, no el número.
Qué preguntarle a tu proveedor
Si no gestionas tú el servidor, esta es la vía corta. Copia y pega:
Buenas. El 14 de octubre nginx publicó cinco avisos de seguridad, corregidos en las versiones 1.31.7 y 1.30.6. ¿Podéis confirmarme qué versión tenemos y si está ya actualizada? Y si usamos alguna de estas:
alias, HTTP/3, AIO o tickets de sesión TLS. Si no está actualizada, ¿cuándo está previsto?
La respuesta te dice más que la versión. Si te contestan en un día con números concretos, tienes un buen proveedor. Si te responden «está todo correcto» sin concretar, ya sabes dónde estás.
Esto no vino solo
nginx fue el primero, pero no el único. El 21 de octubre, una semana después, se parchearon también PHP y Node.js — los otros dos pilares sobre los que funciona cualquier web. Tres avisos en ocho días.
Si tu web funciona con PHP —WordPress, WooCommerce, PrestaShop, Moodle—, el que te toca de verdad es el otro: PHP2Shell: cómo saber si tu web está afectada, con dos fallos que puntúan 9,2 sobre 10.
Y si tienes una aplicación hecha con Node —un panel de clientes, una API, algo a medida—, su actualización del 21 de octubre corrige diez vulnerabilidades, cuatro de ellas graves. Lo contamos aparte.
Lo que hacemos en MagicBoxDesk
Comprobar una versión de nginx son dos minutos. El problema no es ese: es que nadie los dedique, mes tras mes, a las diez o veinte piezas que tiene tu infraestructura.
- Mantenimiento web — tus versiones al día sin que tengas que estar pendiente
- Ciberseguridad — revisión de lo que tienes expuesto a internet
- SOC gestionado 24/7 — alguien mirando cuando tú no estás
Si solo quieres saber si te afecta, escríbenos. Mirar una versión es media hora y no te cuesta nada.
📍 Alicante y Barcelona · magicboxdesk.com
Fuentes
- nginx — Security advisories
- nginx — CHANGES (fecha de la 1.31.7)
- INCIBE-CERT — Múltiples vulnerabilidades en NGINX
- BleepingComputer
- SecurityWeek
