PHP2Shell, Next.js y Node.js: qué ha pasado en octubre de 2026 y cómo saber si tu web está expuesta

Sin rodeos

• Si tu web es un WordPress, el aviso grave es PHP2Shell. Está en PHP, el lenguaje en el que corre WordPress, y se arregla actualizando PHP en el servidor, no la web. Pregúntale a tu hosting qué versión tienes.
• El cortafuegos de tu proveedor ayuda, pero no arregla. Vercel y otros han bloqueado los ataques conocidos. Ellos mismos dicen que hay que actualizar igual.
• Lo peligroso de verdad son los complementos sin actualizar. En las webs WordPress que hemos analizado esta semana, una de cada tres tenía un complemento con un fallo que se está explotando desde agosto.

¿Prefieres que lo miremos nosotros? Pide una revisión gratuita de tu web.

Qué ha pasado

Un fallo de seguridad es un error en un programa que permite a alguien hacer algo que no debería: leer datos, tumbar la web o, en el peor caso, tomar el control del servidor. Se corrigen publicando una versión nueva, y hasta que alguien la instala, la web sigue expuesta. Estos son los cuatro de este mes que más webs de empresa tocan:

Sobre PHP2Shell conviene no exagerar ni quitarle importancia. A 21 de octubre no figuraba en el catálogo de fallos explotados de la agencia de ciberseguridad de EE. UU. y no había ninguna intrusión confirmada públicamente, pero ya circulaban exploits y se habían visto intentos de ataque. Con un fallo crítico, que no requiere contraseña y que afecta a casi cualquier servidor con PHP, esperar a que se confirme es llegar tarde.

Y no es lo único del mes. Otro complemento de WordPress, Bricksforge, se explota desde el 7 de octubre, y se han colado versiones maliciosas de librerías de JavaScript en el repositorio del que las descargan los programadores. Esto último afecta a quien desarrolla, no a la web publicada, pero por eso conviene que alguien revise qué se instala.

«Mi proveedor ya lo bloquea»: por qué no basta

Varios proveedores han reaccionado rápido. Vercel, donde alojamos buena parte de las webs que hacemos, puso reglas en su cortafuegos, en cuanto se publicaron, para PHP2Shell y para el fallo de Node.js , gratis y en todos los proyectos. Es una buena noticia. Pero lo dicen ellos mismos en los dos boletines: las reglas no sustituyen al parche.

Un cortafuegos reconoce los ataques que ya conoce. Si alguien cambia un poco la forma del ataque, o el tráfico llega por un camino que no pasa por él, no lo ve. Es un paraguas mientras actualizas, no la solución. Y si tu web está en un hosting compartido sin nada delante, ni siquiera tienes el paraguas.

Cómo lo gestionamos nosotros

Cuando sale un aviso así, el trabajo no es correr: es saber en minutos a qué afecta. Esta semana, todo lo que mantenemos estaba revisado y actualizado en menos de 24 horas. Así lo hacemos:

1. 1

   Saber qué hay y dónde

   Un inventario al día de cada web, aplicación y servidor que llevamos: con qué está hecho y en qué versión. Sin eso, cada aviso obliga a ir mirando uno por uno.

2. 2

   Ver a quién afecta de verdad

   Muchos fallos solo son explotables si se usa una función concreta. Cruzamos cada aviso con el inventario para saber qué es urgente y qué puede esperar al mantenimiento normal.

3. 3

   Actualizar probando antes de publicar

   Cada actualización pasa primero por una copia de la web y por sus pruebas. Se publica cuando funciona igual que antes, no cuando compila.

4. 4

   Avisar a quien le toca

   Lo que no depende de nosotros, como la versión de PHP de un hosting o una web que mantiene otra empresa, se avisa con qué hay que hacer y en qué plazo.

Y fuera de casa, lo que más se repite: en las webs WordPress que hemos analizado desde fuera estos días, una de cada tres tenía Elementor Pro en una versión afectada por el fallo que se explota desde agosto, y en ninguna se podía saber desde fuera si el PHP del servidor ya estaba al día. Ese es el riesgo real de la mayoría de webs de empresa: no la tecnología, sino que nadie las actualice.

Cómo comprobar tu web sin ser técnico

Seis preguntas. Las puedes hacer tú, o hacérselas a quien te lleva la web:

1. 1

   La versión de PHP del servidor

   Pídesela a tu hosting por escrito. Tiene que ser 8.2.35, 8.3.36, 8.4.27, 8.5.12 o posterior. Si te dicen 8.1 o menos, hay que subir de versión.

2. 2

   Que WordPress y todos los plugins estén al día

   Entra en Escritorio → Actualizaciones. Si hay plugins de pago (Elementor Pro, constructores, formularios), comprueba que la licencia sigue activa: sin ella no se actualizan.

3. 3

   Que haya alguien con nombre que se ocupe

   Una persona o empresa que tenga por escrito que actualiza tu web y en qué plazo. «Ya lo mira el hosting» no suele incluir los plugins.

4. 4

   Una copia de seguridad que alguien haya restaurado alguna vez

   Una copia que nunca se ha probado es una esperanza. Pregunta cuándo fue la última vez que se recuperó una.

5. 5

   Quién tiene acceso de administrador

   Revisa la lista de usuarios con permisos de administración y quita a quien ya no trabaja contigo, incluidas agencias antiguas.

6. 6

   Si tu web es a medida, la versión de su tecnología

   Pregunta a quien la hizo qué versión de Next.js o de Node.js usa y si ya está en las corregidas. Si no sabe responder, eso ya es una respuesta.

Lo que debería incluir un mantenimiento de verdad

Lo que permite revisarlo todo en un día es saber qué hay y dónde, y que alguien vigile para no enterarse por las redes sociales. Si pagas un mantenimiento, o vas a contratarlo, esto es lo mínimo que debería cubrir:

• Parches críticos en días, no en meses. Con un compromiso de plazo por escrito.
• Vigilancia automática. Alertas cuando sale un fallo que afecta a lo que tienes instalado, filtradas para que lleguen las que importan y no cien correos que nadie lee.
• Probar antes de publicar. Cada actualización, primero en una copia; como hemos visto, que compile no significa que funcione.
• Copias de seguridad probadas y una lista al día de quién tiene acceso.
• Un resumen que entiendas. Qué se ha actualizado, qué queda pendiente y por qué.

Preguntas frecuentes