Vulnerabilidades críticas en PHP y Node.js: qué pasó y qué hacer

El pasado 21 de octubre coincidieron dos anuncios de seguridad importantes. Ese mismo día, los responsables de PHP y de Node.js, dos de las tecnologías con las que se construye buena parte de la web, publicaron versiones nuevas para corregir fallos graves. En los dos casos, el peor escenario es el mismo: que alguien, desde fuera y sin usuario ni contraseña, consiga ejecutar instrucciones en el servidor.

Si no tienes claro qué es exactamente una vulnerabilidad o qué significa una puntuación de gravedad, en este artículo lo explicamos desde cero. Aquí vamos a lo concreto: qué pasó, a quién afecta y qué hacer.

¿Qué pasó con PHP?

PHP es el lenguaje en el que están hechos la mayoría de los sitios web que se ejecutan en un servidor, incluidos todos los WordPress, Drupal, Joomla y muchas tiendas en línea como WooCommerce o Magento. Si tu web tiene un gestor de contenidos clásico, lo más probable es que funcione con PHP.

Los fallos se identifican como CVE-2026-109618 y CVE-2026-109619, y en el sector ya se los conoce como PHP2Shell. Tienen una gravedad de 9,2 sobre 10 y permiten que alguien envíe a la web una petición preparada a propósito y, con ella, tome el control del proceso que la atiende. Lo más delicado es que no dependen de tu tema, de tus plugins ni del código que se programó para ti: el fallo está en PHP mismo, y en algunas configuraciones se activa antes de que tu aplicación llegue a ejecutarse.

Afectan prácticamente a todas las versiones de PHP en uso, desde la 5.4 hasta la 8.5. Poco después del anuncio aparecieron programas de ataque públicos, y el 26 de octubre la agencia de ciberseguridad de Estados Unidos (CISA) los incluyó en su catálogo de vulnerabilidades que se están explotando activamente. El FBI llegó a recomendar desconectar los sistemas que no se pudieran actualizar de inmediato.

¿Qué versiones de PHP lo corrigen?

• PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, o posteriores.
• Para 7.4, 8.0 y 8.1, que ya no reciben actualizaciones habituales, se publicaron parches limitados que tu proveedor tiene que aplicar por su cuenta.
• Las versiones más antiguas (7.3, 7.0, la rama 5) no tienen corrección oficial. Si tu web todavía corre sobre una de ellas, la única salida segura es migrar.

Si tu web está en un hosting compartido, la versión de PHP la controla el proveedor. Muchos ya actualizaron, pero conviene confirmarlo en el panel o preguntándoles directamente, porque algunos mantienen versiones viejas activas para no romper sitios antiguos.

¿Qué pasó con Node.js?

Node.js es la tecnología sobre la que corren muchas aplicaciones web modernas, APIs y sistemas internos, y también buena parte de las herramientas con las que se construyen los sitios actuales. Ese mismo 21 de octubre, Node.js corrigió diez fallos en todas sus versiones con soporte.

El más serio, CVE-2026-111497, está en la forma en que Node.js descomprime datos en el formato Brotli. Brotli es un sistema de compresión que se usa en la web para que las páginas y los datos pesen menos al viajar; Node.js los descomprime automáticamente, por ejemplo cuando tu aplicación consulta otro servicio en internet. Un paquete comprimido malformado a propósito puede corromper la memoria y, en el peor caso, permitir ejecutar código. Node.js lo clasifica como grave, y Google, que mantiene la librería Brotli, le dio un 9,2 sobre 10. El 27 de octubre, CISA añadió también este fallo a su catálogo de vulnerabilidades explotadas.

Entre los otros nueve hay varios relacionados con la verificación de certificados y de nombres de dominio. Dicho sin tecnicismos: formas de engañar a una aplicación para que confíe en un servidor en el que no debería confiar.

¿Qué versiones de Node.js lo corrigen?

• Node.js 22.23.4, 24.22.1 y 26.12.1, o posteriores.
• Las versiones fuera de soporte, como Node.js 20 o anteriores, no reciben la corrección.

Un matiz importante: actualizar Node.js en el ordenador de quien programa no actualiza el servidor. Si la aplicación se despliega en contenedores o imágenes preparadas, hay que reconstruirlas con la versión nueva. Y otros programas que incluyen su propia copia de Brotli pueden necesitar su propia actualización.

¿Mi web está afectada?

Unas preguntas rápidas para saberlo:

• ¿Tu web es un WordPress, una tienda WooCommerce o cualquier gestor de contenidos clásico? Entonces usa PHP, y la pregunta es qué versión. Está en el panel del hosting o en la sección de salud del sitio de WordPress.
• ¿Tienes una aplicación a medida, un portal de clientes o una API? Puede estar hecha en PHP o en Node.js. Quien la mantiene debería poder decirte la versión exacta en un minuto. Si nadie sabe responder, eso ya es una señal.
• ¿Tu web es estática? Los sitios que se generan por adelantado y se publican como archivos (como este) no ejecutan PHP ni Node.js al recibir visitas, así que el riesgo es mucho menor. Aun así, conviene actualizar el entorno donde se construyen.

Para ver qué tecnología se detecta desde fuera, puedes pasar tu dirección por nuestro detector de tecnología. Si el resultado muestra la versión exacta de PHP, por ejemplo con una cabecera X-Powered-By, ese dato lo ven también los programas que buscan servidores vulnerables. Ocultarlo es una de las medidas que explicamos en la guía de cabeceras de seguridad HTTP.

¿Qué hacer esta semana?

1. Haz inventario. Anota qué partes de tu presencia digital usan PHP o Node.js y en qué versión: la web, la tienda, el portal de clientes, las integraciones.
2. Actualiza a las versiones corregidas. Lo ideal es probar en una copia primero, pero con fallos de esta gravedad la prueba se mide en horas o días, no en semanas.
3. Si no puedes actualizar todavía, pide a tu proveedor que aplique las medidas temporales publicadas para PHP. Reducen el riesgo, pero no lo eliminan: solo la actualización lo cierra del todo.
4. Revisa si hubo actividad extraña desde el 21 de octubre: usuarios administradores nuevos, archivos modificados, páginas que no reconoces, picos de correo saliente. Si algo no cuadra, trátalo como un incidente y no como una curiosidad.
5. Pon fecha a la migración de lo que ya no tiene soporte. Un PHP 7 o un Node.js 18 no van a recibir el siguiente parche, y habrá un siguiente.

¿Por qué esto vuelve a pasar?

Porque es la naturaleza del software. PHP y Node.js son proyectos maduros, revisados por miles de personas, y aun así aparecen fallos graves. Que se descubran y se corrijan es una buena noticia; lo que marca la diferencia es cuánto tarda cada web en recibir la corrección.

Las empresas que pasaron estas semanas con tranquilidad tienen algo en común: alguien ya sabía qué versiones usaban, leyó el anuncio el mismo día y aplicó el parche con un registro de lo hecho. Ese es justamente el trabajo de nuestro servicio de soporte y evolución continua: vigilar los avisos de seguridad de lo que usas, aplicar las actualizaciones con método, comprobar que las copias de seguridad se restauran y avisarte antes de que lo note un cliente.

Y si la revisión te deja con una plataforma sobre versiones que ya no tienen soporte, la modernización de sistemas heredados es la forma de salir de ahí sin perder lo que funciona. Si quieres que revisemos tu caso, escríbenos y te decimos en qué punto estás.