PHP, Laravel, Node.js, GitLab, eMudhra: alertas de octubre

Entre el 17 y el 22 de octubre de 2026 se publicaron, con pocos días de diferencia, cinco alertas de seguridad: dos fallos críticos en PHP, el lenguaje en el que funciona la mayoría de los sitios web, conocidos como PHP2Shell; un fallo en Laravel que permite a un atacante actuar como otro usuario; diez correcciones en Node.js; un fallo crítico en los servidores GitLab que las empresas gestionan por su cuenta, y claves débiles en eMudhra, una empresa que emite los certificados que protegen las conexiones a sitios web. Una empresa con un sitio web en Laravel, su código en un GitLab propio y algunos servicios en línea puede tener que actuar en los cinco frentes.

Nuestra opinión: la primera pregunta no es qué fallo es el peor. Es dónde usa su empresa cada uno de estos productos y a cuáles de esos sistemas puede llegar cualquiera desde internet. Un equipo solo puede corregir lo que sabe que tiene.

Este software está en todas partes

PHP mueve cerca de 7 de cada 10 sitios web del mundo, y más de 8 de cada 10 sitios .es en España, según W3Techs (octubre de 2026). Solo WordPress, que está hecho en PHP, está detrás de casi el 40 % de todos los sitios web. Drupal también está hecho en PHP.

Las herramientas con las que los desarrolladores crean sitios web están igual de extendidas. Laravel se ha descargado más de 600 millones de veces. Symfony, en el que se apoyan el propio Drupal y el propio Laravel, más de 900 millones de veces.

Aun así, muchos propietarios no saben con qué funciona su propio sitio web. La plataforma la eligió una agencia, las herramientas un proveedor y el servidor lo gestiona el hosting. Una empresa que «solo tiene un WordPress» usa PHP, y la alerta de PHP2Shell le afecta.

Los atacantes no esperan a que los propietarios se enteren. El equipo de seguridad de Amazon escribe que las herramientas de IA abaratan convertir una corrección o un aviso publicados en un ataque que funciona, así que el tiempo entre la corrección y los primeros ataques sigue acortándose. En PHP2Shell, los intentos de ataque empezaron incluso antes de que saliera la corrección.

Primero la lista, después el parche

La recomendación oficial sobre PHP2Shell empieza por el mismo sitio. CISA, la agencia de ciberseguridad de Estados Unidos, pide a las organizaciones «identificar e inventariar los sistemas que ejecutan cualquier versión de PHP», empezando por los accesibles desde internet, y advierte de que PHP «suele ser un componente de otro software». El NCSC del Reino Unido da el mismo primer paso.

Las otras cuatro alertas plantean la misma pregunta. ¿Cuáles de nuestros sitios web funcionan con PHP o Laravel? ¿Nuestro GitLab propio está abierto a internet? ¿Qué sistemas nuestros siguen usando un Node.js antiguo o una lista de certificados de confianza desactualizada? Un equipo solo puede responder por los sistemas que conoce. Un sistema que no está en la lista puede quedarse sin actualizar, por ejemplo:

una copia de pruebas de un sitio web que siguió en línea al terminar un proyecto;
un servidor GitLab que montó hace años un desarrollador que ya no está en la empresa;
un sitio web que creó una agencia y que sigue alojado en su propia cuenta;
el sitio web de una oficina regional gestionado fuera del departamento de TI central.

Una revisión puntual da una foto fija. Esta semana muestra por qué la lista tiene que estar al día: cinco alertas en seis días, y cada una exige su propia respuesta a «¿dónde usamos esto?». El análisis externo periódico mantiene esa lista al día a medida que aparecen y cambian sitios web. Muestra a qué sistemas suyos puede llegar cualquiera desde internet y qué tecnologías y versiones dejan ver: el servidor web, la plataforma del sitio, el lenguaje de programación.

Ocultar la versión ayuda un poco: desde fuera es más difícil saber si su sitio está afectado. No le protege. Las herramientas automáticas de los atacantes no se quedan en el número de versión: prueban el propio fallo. Una versión oculta también impide que un análisis externo la asocie a un fallo conocido, y algunas cosas, como los componentes exactos dentro de una aplicación, no se ven desde fuera en absoluto. Esas respuestas las dan su equipo de TI y sus proveedores.

¿Es un ataque coordinado?

Las fuentes que consultamos no vinculan estos cinco problemas a una misma campaña. El servicio de seguimiento de vulnerabilidades cve.tools contó 203 vulnerabilidades críticas nuevas esa semana, más o menos lo habitual para seis días (214 de media desde abril). Lo que hizo inusual la semana es que varias piezas del mismo software web tan extendido necesitaron correcciones a la vez, y que en PHP los ataques empezaron antes de la corrección.

Las cinco alertas, una por una

1. PHP2Shell: fallos en el propio PHP (CVE-2026-109618, CVE-2026-109619)

Qué es. Dos fallos en PHP que, según el propio aviso de PHP, «pueden permitir la ejecución remota de código sin autenticación»: un atacante podría tomar el control del servidor sin iniciar sesión. PHP califica ambos con 9,2 sobre 10.
A quién afecta. PHP señala «todas las instalaciones de PHP que atienden peticiones web». Eso incluye los sitios hechos con Laravel, WordPress, Drupal y otro software en PHP. Actualizar el sitio o su plataforma no actualiza el PHP que hay debajo.
¿Se está atacando? Sí, hay intentos. Amazon vio el primero en sus servidores señuelo el 17 de octubre, cuatro días antes de la corrección, y escribe que PHP2Shell está siendo objeto de «amplios intentos de explotación». Amazon no indica si ese primer intento tuvo éxito.
Qué hacer. Pida a quien gestiona sus sitios web que actualice PHP y lo reinicie. Las versiones antiguas de PHP que ya no reciben actualizaciones necesitan un paquete corregido del proveedor o el paso a una versión con soporte. Las versiones están en la lista de comprobaciones de abajo; más detalles en nuestra nota sobre PHP2Shell.

2. Laravel: actuar como otro usuario sin iniciar sesión (CVE-2026-114509)

Qué es. Con ciertas configuraciones de la base de datos, un atacante sin cuenta puede hacer que la comprobación de claves de acceso integrada en Laravel acepte al usuario equivocado, y actuar después como ese usuario. Laravel lo califica como crítico, 9,2 sobre 10.
A quién afecta. A los sitios y aplicaciones en Laravel que usan esa comprobación integrada, llamada TokenGuard, con una versión antigua de Laravel. Laravel publicó la corrección el 19 de octubre.
¿Se está atacando? Laravel no informa de ataques.
Qué hacer. Pregunte a sus desarrolladores si su aplicación usa TokenGuard y pídales que actualicen Laravel. Las versiones están en la lista de comprobaciones.

3. Node.js: diez correcciones, cuatro de gravedad alta

Qué es. El 21 de octubre Node.js corrigió diez fallos. Los más graves podrían permitir a un atacante ejecutar código en un servidor o saltarse la comprobación de que una conexión segura va de verdad al sitio correcto.
A quién afecta. A todas las versiones con soporte, tanto en los servidores en marcha como en los sistemas que compilan sus aplicaciones. Las versiones antiguas sin soporte no reciben correcciones.
¿Se está atacando? Node.js no informa de ataques.
Qué hacer. Pida a sus desarrolladores que pasen cada aplicación, y los sistemas que la compilan, a una versión corregida y la vuelvan a desplegar. Las versiones están en la lista de comprobaciones.

4. GitLab: tomar el control del servidor de código de una empresa (CVE-2026-110264)

Qué es. El 21 de octubre GitLab corrigió un fallo que, «en determinadas condiciones», podía permitir a alguien sin cuenta ejecutar código en un servidor GitLab, donde una empresa guarda su código fuente. GitLab lo califica con 10 sobre 10, el máximo de la escala. El 12 de octubre ya había corregido otro fallo de 10 sobre 10.
A quién afecta. A las empresas que tienen GitLab en sus propios servidores, con cualquier versión anterior a la corrección. GitLab.com, el servicio en la nube, ya está corregido.
¿Se está atacando? GitLab no informa de ataques. Ha publicado reglas para detectar intentos.
Qué hacer. Actualice. Si se puede acceder a su GitLab desde internet, empiece por él.

5. eMudhra: una autoridad de certificación con claves que cualquiera podía deducir

Qué es. eMudhra emite certificados, las identificaciones digitales que protegen las conexiones a sitios web (el candado del navegador). Las claves secretas de ocho de sus certificados se generaron tan mal que cualquiera puede deducirlas a partir de los certificados públicos. Con una de ellas, un atacante podría hacerse pasar por un sitio web o un servicio ante el software que aún confía en estos certificados. Las claves son de abril de 2025; el problema se descubrió en octubre de 2026.
A quién afecta. Los navegadores actualizados están protegidos: Firefox y Chrome bloquean estos certificados desde el 17 de octubre, Microsoft desde el 20 y Apple desde el 22. Lo expuesto es el software que no recibe estas actualizaciones: servidores, contenedores y aplicaciones con su propia lista de certificados de confianza, por ejemplo un sitio web que se conecta a una pasarela de pago o a una empresa de envíos.
¿Se está atacando? No se sabe. Los investigadores que descubrieron el problema escriben: «No sabemos si los atacantes aprovecharon la generación defectuosa de claves».
Qué hacer. Pida a su equipo de TI que actualice la lista de certificados de confianza en los servidores y en los contenedores, y que haga la prueba de la lista de comprobaciones.

Para su equipo de TI: primeras comprobaciones, por orden

Haga una lista de sus sitios web, subdominios y servicios accesibles desde internet, incluidos los que gestionan agencias, filiales y proveedores de alojamiento. Marque cuáles usan PHP, Laravel, Node.js o GitLab.
PHP: confirme que la versión en uso es 8.5.12, 8.4.27, 8.3.36, 8.2.35 o un paquete corregido de la distribución, y que se reiniciaron los procesos de PHP. En contenedores, reconstruya desde la imagen base corregida. php -v solo muestra el PHP de línea de comandos: confirme por separado la versión que usa el servidor web (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) y reinicie o vuelva a desplegar sus procesos.
Laravel: ejecute composer show laravel/framework. Si es anterior a 12.68.0, o 13.x anterior a 13.29.0, y la aplicación usa TokenGuard, actualícelo primero.
Node.js: pase a 26.12.1, 24.22.1 o 22.23.4 en los Dockerfile (FROM node:), en CI y en los archivos .nvmrc; después despliegue y compruebe la versión en marcha.
GitLab: si tiene uno propio, actualícelo a 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 o 18.11.13, y compruebe si se puede acceder a él desde internet.
Certificados: actualice ca-certificates en los servidores y en las imágenes, y los entornos de ejecución que llevan su propia lista de certificados (la página de divulgación de los investigadores indica las versiones corregidas de Node.js, Go, Python y otros). Después compruébelo: curl https://dv-g3b-emudhra.we-have-a-problem.com/ debe fallar con un error de certificado. Si la conexión se completa, ese cliente acepta la cadena probada.
Revise la actividad anterior: en PHP2Shell, Amazon recomienda revisarla como mínimo desde el 17 de octubre, no desde el día de la publicación. Busque peticiones inusuales a sitios PHP, procesos de PHP que abren una shell o descargan herramientas y cambios inesperados en archivos. Si encuentra algo, trate el servidor como comprometido: actualizar no expulsa a un atacante que ya ha entrado.

Preguntas frecuentes

¿Cuáles están usando los atacantes?

PHP2Shell: Amazon informa de intentos, antes y después de la corrección. Laravel, Node.js y GitLab: los fabricantes no informan de ataques. eMudhra: no se sabe, y los investigadores lo dicen. Ninguno figuraba en la lista de CISA de ataques confirmados cuando lo comprobamos, lo que no demuestra que no los haya.

Nuestro sitio web funciona con Laravel. ¿Basta con actualizar Laravel?

No. Laravel funciona sobre PHP, y PHP2Shell está en el propio PHP. PHP necesita su propia actualización, y Laravel otra aparte para su propio fallo.

Mi navegador está actualizado. ¿Estoy a salvo del problema de eMudhra?

Si su navegador y su sistema operativo tienen las últimas actualizaciones, sí. Eso no dice nada de sus servidores ni de los servicios con los que se conecta su sitio web: pida a su equipo de TI que actualice sus listas de certificados.

Usamos GitLab.com, no un servidor propio. ¿Tenemos que hacer algo?

No por este fallo. GitLab indica que GitLab.com ya usa la versión corregida.

¿No sabe qué sistemas suyos son accesibles desde internet ni qué ejecutan? SeguriScan, la plataforma de IntruForce, examina desde fuera los sistemas de su empresa accesibles desde internet. Vea cómo SeguriScan muestra un hallazgo en uno de sus activos y qué corregir primero. Para probarlo con sus propios sistemas, solicite un piloto gratuito de SeguriScan con el formulario de abajo. Primero acordamos con usted el alcance y los sistemas que se evaluarán, y confirmamos que tiene autorización para solicitar la revisión. No se analiza nada antes. Después obtiene acceso a la plataforma SeguriScan con los activos descubiertos, los hallazgos y los informes. Sin compromiso de continuar.

Fuentes (en inglés)

PHP: aviso de seguridad del 21 de octubre de 2026 y avisos GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp.
Laravel: aviso GHSA-f9x3-7vq9-cph6 (19 de octubre de 2026).
Node.js: versiones de seguridad de octubre de 2026 (21 de octubre de 2026).
GitLab: actualización de seguridad crítica 19.5.1 (21 de octubre de 2026) y actualización 19.4.2 (12 de octubre de 2026).
eMudhra: página de divulgación de los investigadores y Mozilla Bugzilla, bug 2083449 (comentarios 5 y 11).
Amazon Threat Intelligence: explotación de PHP2Shell anterior a la divulgación pública, detectada en MadPot (21 de octubre de 2026).
CISA: alerta sobre vulnerabilidades críticas de PHP (21 de octubre de 2026) y catálogo de vulnerabilidades explotadas conocidas, versión 2026.10.21.
NCSC: problema de seguridad crítico que afecta a PHP.
Estadísticas de la semana: cve.tools, con una cronología detallada y gráficos.
Cifras de uso: W3Techs, 23 de octubre de 2026: PHP, 69,3 % de los sitios web cuyo lenguaje de servidor detecta, y 82,8 % de esos sitios .es; WordPress, 39,6 % de todos los sitios; Drupal, 0,6 %. Descargas totales en Packagist, el directorio de paquetes de PHP, 23 de octubre de 2026: Laravel (laravel/framework), 602 millones; componente central de Symfony symfony/http-kernel, 946 millones.

Cinco alertas de seguridad en una semana: PHP, Laravel, Node.js, GitLab, eMudhra