En un solo día, el 21 de octubre, han salido a la luz vulnerabilidades críticas en tres piezas de software muy extendidas: PHP, Node.js y GitLab. Se usan para que funcionen webs, aplicaciones y entornos de desarrollo, así que un fallo en ellas puede afectar a muchas empresas a la vez.
Antes de ver cada caso, una idea clave: el riesgo más grave en los tres es la ejecución remota de código. Dicho de forma sencilla, significa que alguien desde internet podría llegar a dar órdenes a un servidor como si fuera suyo: acceder a datos, modificar webs o usarlo para otros ataques.
PHP
Qué es: el lenguaje de programación con el que funcionan muchísimas webs, entre ellas las creadas con WordPress, Drupal o Joomla. Sus descubridores estiman que está detrás de en torno al 70 % de los sitios web.
Qué ha pasado: dos vulnerabilidades críticas (CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell), de 9,2 sobre 10 en la escala de gravedad CVSS v4.0. Nacen de cómo PHP gestiona ciertos errores, sobre todo cuando se queda sin memoria atendiendo una petición web. En esos casos puede dejar datos internos «sucios» que la siguiente petición reutiliza, como una pizarra que no se borra del todo entre una persona y la siguiente. Un atacante puede aprovecharlo para ejecutar código en el servidor sin usuario ni contraseña, enviando peticiones web manipuladas.
Por qué importa: el fallo está en el propio PHP, no en la aplicación que funciona encima. Los investigadores lo demostraron sobre WordPress, Drupal y Joomla, y afecta a versiones desde PHP 5.4. Incluso una aplicación sencilla y bien programada podría estar expuesta.
Según sus descubridores (Wiz Research), la inteligencia artificial fue clave para localizar fallos que llevaban más de una década en el código y convertirlos en ataques funcionales. Esa misma capacidad reduce el esfuerzo necesario para atacar, por lo que conviene actualizar sin demora. Las medidas de mitigación reducen la exposición, pero no hacen segura una instalación: la única solución completa es actualizar.
Versiones corregidas: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las versiones 8.1 y anteriores ya no reciben actualizaciones del proyecto PHP.
Node.js
Qué es: el entorno que permite ejecutar JavaScript en el servidor, muy usado en aplicaciones web y APIs.
Qué ha pasado: diez vulnerabilidades, cuatro de ellas de gravedad alta (no crítica). La más relevante afecta a Brotli, un sistema de compresión de datos, algo parecido a un «zip» para la web. Si una aplicación descomprime datos manipulados por un atacante, podría acabar ejecutando código. Otras dos permitirían engañar a la comprobación que verifica que un certificado pertenece realmente al servidor con el que nos conectamos.
Por qué importa: el riesgo depende de cómo esté hecha cada aplicación. En el caso de Brotli, solo está expuesta la que procesa datos comprimidos de origen no confiable.
Versiones corregidas: Node.js 26.12.1, 24.22.1 y 22.23.4. Las versiones 20 y anteriores ya no reciben actualizaciones de su proyecto.
GitLab
Qué es: una plataforma para guardar el código de las aplicaciones y automatizar sus pruebas y despliegues (lo que se conoce como CI/CD). Quien la tiene instalada en sus propios servidores guarda ahí su código y credenciales de acceso a otros sistemas.
Qué ha pasado: una vulnerabilidad crítica (CVE-2026-110264), de 10 sobre 10 en CVSS v3.1, la puntuación máxima. Bajo ciertas condiciones, permitiría a alguien sin cuenta ejecutar código en el servidor enviando una expresión regular (un patrón de búsqueda de texto) manipulada, que GitLab procesa mal por un error de cálculo.
Por qué importa: afecta a GitLab instalado en servidores propios (Community y Enterprise Edition), en todas las versiones desde la 7.0 hasta las corregidas. GitLab.com ya está corregido. Además, es el segundo fallo crítico en este mismo componente en nueve días: el anterior se corrigió el 12 de octubre, así que quien actualizó entonces sigue afectado y debe volver a actualizar.
Versiones corregidas: GitLab 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 y 18.11.13.
Qué hemos hecho en Linube
Si Linube administra tus sistemas, ya estamos trabajando en ello desde el primer momento, en tres frentes:
- Reducir la exposición cuanto antes. Donde existen medidas de mitigación recomendadas, las hemos aplicado como primera barrera. Son un paso provisional: la única forma de cerrar estas vulnerabilidades por completo es actualizar.
- Aplicar los parches. En cuanto estuvieron disponibles, empezamos a instalarlos, y seguimos haciéndolo.
- Comprobar el resultado. Continuamos con las actualizaciones y con las verificaciones correspondientes en cada uno de los entornos.
Si no administramos tus sistemas la comprobación tiene que partir de ti. Te recomendamos hablar cuanto antes con tu equipo de IT, o con el proveedor que gestione tus servidores y aplicaciones, para confirmar si utilizáis PHP, Node.js o GitLab instalado en servidores propios, en qué versiones, y si hay que actuar. Y si te afecta y no puedes gestionarlo por tu cuenta, háznoslo saber y te ayudamos a valorar las opciones.
Seguimos atentos
La información evoluciona rápido y mantenemos abierta la evaluación del alcance. Si hay algo relevante para tu servicio, o una actuación que requiera tu participación, te lo comunicaremos.
¿Tienes dudas? Escríbenos y te ayudamos.
