Del 14 al 21 de octubre de 2026 se publicaron cuatro avisos de seguridad graves. No son cuatro avisos cualesquiera: entre ellos cubren las cuatro capas sobre las que funciona prácticamente cualquier web de empresa.
| Día | Qué pasó | Capa |
|---|---|---|
| 14 de octubre | nginx publica la 1.31.7 con cinco avisos de seguridad | el servidor web |
| 15 de octubre | se publica CVE-2026-98432, un fallo de 9,8 sobre 10 en el núcleo de Linux | el sistema operativo |
| 21 de octubre | PHP corrige PHP2Shell: dos fallos de 9,2 | el lenguaje |
| 21 de octubre | Node.js publica diez CVE, cuatro graves | el lenguaje |
Ocho días. Cuatro capas. Si tu empresa tiene una web, una tienda, un portal de clientes o cualquier aplicación a la que se entre por navegador, lo más probable es que al menos dos de los cuatro estén funcionando en tu servidor ahora mismo. Y bastante probable que no sepas en qué versión.
Este artículo no repite lo que ya puedes leer en diez sitios. Responde a lo único que importa cuando llevas una empresa: cuál te toca a ti, cómo averiguarlo sin ser administrador de sistemas, y qué haces con el que todavía no tiene parche.
Lo que de verdad llama la atención no es que fueran cuatro
Cuatro avisos graves en ocho días es inusual, pero por sí solo no dice gran cosa: el software se parchea constantemente y que haya semanas cargadas entra dentro de lo normal.
Lo que convierte esto en otra cosa son dos hechos concretos.
1. Van en capas distintas, y una de ellas lo compromete todo
Los tres de octubre —nginx, PHP y Node— afectan a lo que ejecuta tu web. Un atacante que los aprovecha se lleva tu aplicación.
El del kernel es diferente. El kernel es el programa que está por debajo de todos los demás: reparte la memoria, habla con el disco y con la red, y decide qué se ejecuta. Todo lo que corre en tu servidor corre encima de él.
| Un fallo en… | Lo que compromete |
|---|---|
| nginx, PHP, Node | tu web o tu aplicación |
| el kernel | la máquina entera, y todo lo que haya dentro |
Si en tu servidor conviven la web, la base de datos y las copias de seguridad —que es exactamente lo normal en una pyme— el del kernel les llega a las tres a la vez.
2. «Actualiza» dejó de ser una respuesta que pudieras seguir
Esta es la parte que no se está contando, y es la importante.
El consejo estándar ante un aviso de seguridad es actualizar. Funciona casi siempre. En esta tanda falló dos veces:
- En Node no hay mitigación limpia. Uno de los diez fallos está en Brotli, la compresión, que no se puede desactivar sin romper el sitio. Y otros dos están en la validación de certificados, que es lo último que querrías apagar. O se actualiza, o hace falta algo delante que filtre.
- En el kernel, si usas Ubuntu, todavía no hay parche. Veintidós días después del aviso, Debian y Red Hat ya lo han corregido y Ubuntu lo sigue teniendo pendiente, tanto en 24.04 como en 22.04.
🔴 Comprobado el 6 de noviembre de 2026 en el tracker de seguridad de Ubuntu: el estado sigue siendo pending para
noble(6.8.0-149.149) y parajammy(5.15.0-203.213). Es un dato que cambia de un día para otro: compruébalo tú mismo antes de dar nada por hecho.
Eso deja a mucha gente en un sitio incómodo: sabe que tiene el fallo, sabe que es grave, y no tiene nada que instalar. Lo que se hace en ese hueco es lo que separa una empresa que gestiona su riesgo de una que solo aplica actualizaciones.
Cuál te afecta: los cuatro comandos
Si tienes acceso al servidor, esto te lo resuelve en cinco minutos.
| Qué | Comando | Estás bien si tienes |
|---|---|---|
| nginx | nginx -v | 1.31.7 o 1.30.6 o superior |
| PHP | php -v | la versión parcheada de tu rama (ver el artículo de PHP2Shell) |
| Node | node -v | v26.12.1, v24.22.1 o v22.23.4 o superior |
| kernel | uname -r | según tu rama: 5.10.272 · 5.15.223 · 6.1.190 · 6.6.159 · 6.12.113 |
Y si no tienes acceso al servidor —que es lo más habitual— cada uno de los cuatro artículos de la serie explica cómo comprobarlo desde fuera, desde el panel del hosting, o qué pedirle exactamente a quien te lleva el servidor.
Las cuatro trampas
Ninguna de estas es teórica. Las cuatro hacen que el comando de arriba te dé una respuesta que parece buena y no lo es:
- Si la aplicación corre en Docker,
node -vte miente. Te da el Node del servidor, no el del contenedor, que lleva el suyo propio. Hay que preguntar dentro del contenedor. - Tener una versión vulnerable de nginx no significa estar expuesto. Los cinco fallos afectan a funciones concretas. Si no usas esos módulos, tu riesgo real es otro. Conviene saberlo antes de parar nada a las dos de la mañana.
- Ubuntu no numera el kernel como el resto. Usa su propia numeración (
6.8.0-146-generic), así que comparar con la tabla de arriba no sirve: lo que importa es el número que va después del guion. - Tu proveedor de hosting puede tenerlo ya parcheado sin decírtelo —o no tenerlo. Eso no se adivina: se pregunta, y se pide por escrito.
Qué hacer cuando no hay parche
Esta es la pregunta que de verdad deja octubre, y merece una respuesta honesta en lugar de un «mantén todo actualizado».
Lo primero: no todo riesgo se elimina. Parte se reduce y parte se acepta a sabiendas. La diferencia entre hacerlo bien y mal no es tener parche o no tenerlo; es saber en cuál de los dos sitios estás.
Lo que sí se puede hacer mientras no hay parche:
- Reducir la superficie. Mirar qué puertos tienes realmente abiertos a internet, y cerrar los que no hagan falta. La mayoría de servidores tienen escuchando cosas que nadie recuerda haber puesto.
- Filtrar delante. Un cortafuegos o un proxy pueden descartar el tipo de tráfico que usa el ataque antes de que llegue al servicio vulnerable. No elimina el fallo: lo pone más lejos.
- Mitigar con conocimiento de causa. Las mitigaciones bloquean tráfico, y a veces tráfico legítimo. Hay que medir primero —contar cuántos paquetes afectaría— antes de descartar nada, y probarlo fuera de producción. Una mitigación aplicada a ciegas un viernes es peor que el fallo.
- Dejar constancia. Que quede escrito qué se detectó, qué se decidió y por qué. El día que haya que justificarlo ante un cliente, un seguro o una auditoría, eso es lo que vale.
- Y poner una fecha de revisión. Una mitigación es temporal por definición. Cuando salga el parche hay que actualizar y retirarla, porque si no se queda ahí bloqueando tráfico legítimo para siempre.
Lo que octubre dice de tu empresa
Las cuatro veces, la primera pregunta fue la misma: ¿qué versión tengo?
Y las cuatro veces, en la mayoría de empresas, nadie supo contestar en el momento. Hubo que entrar a mirar. En algunas, buscar primero a quién había que preguntar.
Ese es el problema de verdad, y no es un problema técnico. Es que no existe una lista de qué software corre dónde, en qué versión y quién responde de él. Mientras no exista, cada aviso de seguridad se convierte en una tarde de investigación — y cuatro avisos en ocho días, en una semana perdida.
Una empresa que tiene esa lista responde a un aviso en diez minutos: mira, decide y actúa. Y en los casos como el del kernel, en los que no hay nada que instalar, puede dedicar ese tiempo a lo que sí sirve en lugar de a averiguar qué tiene.
Si te has pasado octubre preguntando «¿esto me afecta?», el trabajo pendiente no es parchear. Es hacer el inventario.
Los cuatro, uno a uno
Cada aviso tiene su artículo, con el comando exacto, la trampa de cada caso y qué hacer si no puedes actualizar:
- nginx — cinco fallos corregidos el 14 de octubre · por qué tener versión vulnerable no es lo mismo que estar expuesto
- El kernel de Linux — el fallo de TCP que en Ubuntu todavía no puedes parchear · 9,8 sobre 10, desde internet y sin credenciales
- PHP2Shell — cómo saber si te afecta · dos fallos de 9,2 en el lenguaje que mueve la mitad de la web
- Node.js — diez fallos de octubre · el candado está puesto y no sirve; y si va en Docker,
node -vte miente
⚠️ Comprobar las URL exactas antes de subir.
Lo que hacemos en MagicBoxDesk
Damos servicio a empresas de Alicante y Barcelona: mantenimiento de servidores y de web, y seguridad para pymes que no tienen —ni necesitan— un departamento de informática propio.
Si después de leer esto no sabes qué versiones tienes, o sabes que tienes alguna vulnerable y no sabes qué hacer con ella, escríbenos y lo miramos. Decirte que estás bien también es una respuesta válida, y la damos igual.
Fuentes
- nginx CHANGES — versiones 1.31.7 y 1.30.6
- Node.js — October 2026 Security Releases
- Ubuntu Security — CVE-2026-98432 — publicado el 15-10-2026; estado del parche por versión
- Debian Security Tracker y Red Hat CVE Database
- CISA — Known Exploited Vulnerabilities