Una vulnerabilidad «-Shell» es un fallo de ejecución remota de código (RCE) en un software. El sufijo «-Shell» se popularizó con Log4Shell (CVE-2021-44228) en diciembre de 2021. React2Shell sustituyó el 4 por un 2 en diciembre de 2025, y la comunidad investigadora siguió esta convención de nomenclatura a la hora de bautizar los fallos de octubre. PHP reveló PHP2Shell el 21 de octubre de 2026, y Node.js publicó sus correcciones para Node2Shell ese mismo día. Cualquiera de los dos habría sido, por sí solo, la noticia de seguridad del año.
Si tu pila de tecnologías utiliza PHP, Node.js, React o Java, es probable que al menos una de ellas formara parte de ella si la utilizabas hace unos años.
¿Qué tienen en común todas las vulnerabilidades del shell?
Todas las vulnerabilidades de tipo «shell» se encuentran por debajo de la aplicación, en una biblioteca de registro, un marco de interfaz de usuario, un entorno de ejecución del lenguaje o un decodificador de compresión. En el caso del exploit demostrado y notificado de PHP contra Apache con mod_php, PHP2Shell se activa mientras PHP aún está procesando la solicitud entrante, antes de que se ejecute ni una sola línea de tu aplicación. React2Shell afectó a aplicaciones que nunca habían definido una función de servidor propia. Un equipo puede escribir código cuidadoso y bien revisado y, aun así, quedar expuesto, ya que la parte vulnerable no es algo que ellos hayan escrito.
En todas estas vulnerabilidades de shell, los datos de entrada controlados por el atacante llegaban a código que los trataba como seguros. Log4j interpretaba texto que solo debía registrar, y React reconstruía objetos a partir de cargas útiles de Flight sin comprobar su estructura. Express 5 y body-parser 2.x descodifican los cuerpos de solicitud Brotli de cualquier cliente que los envíe, a menudo antes de que se ejecute cualquier comprobación de autenticación.
Ninguna de estas vulnerabilidades requiere que el atacante inicie sesión. Basta con una solicitud manipulada para ejecutar código en el servidor. Node2Shell también tenía una segunda vía de ataque, ya que una respuesta manipulada a una solicitud realizada por tu aplicación también puede activarla.
La mayoría de los equipos también heredan el componente vulnerable sin haberlo elegido nunca. Log4j solía llegar como una dependencia de otra dependencia, y Node.js y PHP se incluyen en imágenes de contenedor que rara vez se recompilan hasta que algo lo obliga. Brotli va aún más allá, ya que su decodificador está integrado en entornos de ejecución y proxies como Node.js, Bun, .NET y Envoy. En Python, los clientes HTTP más populares, como requests y httpx, cargan Brotli automáticamente cuando está presente, y algunos paquetes, como Scrapy, lo instalan como dependencia, por lo que una aplicación puede quedar expuesta sin que se haya importado Brotli en ninguna parte de su propio código.
Resumen de las vulnerabilidades de Shell
Vulnerabilidades de shell por corrupción de memoria (PHP2Shell y Node2Shell)
PHP2Shell se encuentra en el código C del propio motor de PHP, mientras que Node2Shell se encuentra en Brotli, una biblioteca de compresión en C que Node.js y muchas otras plataformas compilan en su propio código. Ambos se dieron a conocer gracias a una investigación asistida por IA, aunque en el caso de PHP2Shell los modelos completaron un trabajo que los humanos habían iniciado años antes.
PHP2Shell (CVE-2026-109618 y CVE-2026-109619)
Un proceso de PHP gestiona una solicitud tras otra, reservando memoria para cada una de ellas y liberándola una vez finalizada la solicitud. Ambos fallos de PHP2Shell obligan a PHP a quedarse sin memoria en un momento concreto, por lo que una solicitud se interrumpe a mitad de su ejecución y deja un puntero a memoria que ya ha sido liberada. La siguiente solicitud del atacante llena esa memoria con datos manipulados, y PHP los lee como si fueran uno de sus propios objetos internos.
La vulnerabilidad CVE-2026-109618 se aprovecha mientras PHP está configurando los datos de la solicitud, y la vulnerabilidad CVE-2026-109619 se aprovecha del estado que el trabajador mantiene entre solicitudes, siendo el progreso de la subida de la sesión —que está habilitado por defecto— una de las vías confirmadas.
El código vulnerable se remonta a PHP 5.4, lanzado en 2012, y la idea en la que se basa se remonta a un error relacionado con el límite de memoria que Stefan Esser descubrió en 2004. Una auditoría realizada en 2024 sacó a la luz el mismo problema, pero nadie pudo demostrar que fuera explotable, por lo que la corrección quedó en suspenso. En agosto de 2026, el investigador californiano Ryan Austin utilizó la inteligencia artificial para lograr lo que la auditoría no había conseguido y convirtió el fallo en una ejecución de código funcional.
Los detalles se filtraron antes de la divulgación prevista; PHP lanzó las correcciones un día antes de lo previsto, el 21 de octubre, y Cloudflare informó de que ya se habían producido ataques ese mismo día. Nuestro aviso sobre PHP2Shell incluye las versiones afectadas, las medidas de mitigación y cómo aplicar los parches, y lo mantenemos actualizado a medida que cambian las recomendaciones.
Node2Shell (CVE-2026-111497)
Node.js incluye su propia copia de Brotli, la biblioteca de compresión de Google, y Node2Shell es un error en el decodificador de Brotli por el que unos datos comprimidos manipulados hacen que escriba más allá del final de un búfer de memoria.
El equipo de seguridad de Codex de OpenAI lo ha calificado como una vulnerabilidad de ejecución remota de código que funciona en ambos sentidos, por lo que un cliente malintencionado puede hacerse con el control de un servidor sin parches y un servidor malintencionado puede hacerse con el control de un cliente sin parches que acepte respuestas comprimidas. En Node.js, Express 5 y body-parser 2.x descodifican automáticamente los cuerpos de las solicitudes en formato Brotli, y fetch() hace lo mismo con las respuestas.
Los investigadores lograron ejecutar código en una imagen de Node.js 24.22.0 sin modificar, pero su exploit no funcionó en todos los intentos, por lo que, en la práctica, lo más probable es que se produzca un fallo del sistema o una fuga de memoria. Nuestro aviso sobre Node2Shell enumera las versiones corregidas para cada línea de lanzamiento.
HTTP2Shell y Broccoli2Shell
El decodificador de Brotli se incluye en muchas más plataformas además de Node.js, por lo que este mismo fallo ha recibido nombres como HTTP2Shell y Broccoli2Shell (HTTP2Shell y Broccoli2Shell hacen referencia al mismo fallo de Brotli en Node.js). Ya hay parches disponibles para Node.js, Bun, Envoy, Istio, .NET, Python, Java brotli4j, libbrotli, Ubuntu y varias distribuciones de Linux, mientras que SUSE y los repositorios estándar de Red Hat Enterprise Linux aún no disponen de una solución.
Los responsables de Brotli ya habían corregido el error en su código fuente el 27 de febrero, pero nadie lo identificó como un problema de seguridad, por lo que no se incluyó en ninguna versión hasta el 21 de octubre. Los proyectos incorporan versiones publicadas de Brotli, por lo que todas las copias en circulación permanecieron vulnerables durante ocho meses, y cada proyecto tuvo que lanzar su propia actualización según su propio calendario. Aikido Security realiza un seguimiento de cada una de ellas en una tabla en tiempo real con el estado de los parches.
Vulnerabilidades de Logic 2Shell (Log4Shell y React2Shell)
Log4Shell y React2Shell se produjeron en Java y JavaScript, lenguajes que gestionan la memoria automáticamente, por lo que no se produce ninguna corrupción de datos. Las vulnerabilidades residen en el diseño de una función, que permitía que la entrada de un atacante determinara qué código ejecutaba el servidor. Ambas obtuvieron una puntuación CVSS perfecta de 10,0 🏆.
Log4Shell (CVE-2021-44228)
Log4j es una biblioteca de registro de Java, y Log4j 2 admitía búsquedas (marcadores de posición escritos como ${...}) que sustituía por un valor real, como una variable de entorno, cada vez que escribía un mensaje. Lo hacía con cualquier texto que registrara, incluido el de los usuarios. Un tipo de consulta, ${jndi}, indica a Java que recupere un objeto de un servidor de directorios, por lo que un atacante que introdujera una consulta ${jndi} apuntando a su propio servidor en el encabezado de un navegador o en un mensaje de chat de Minecraft podría hacer que Log4j descargara una clase de Java y la ejecutara.
La mayoría de las aplicaciones registran parte de la información introducida por el usuario, lo que convertía a casi cualquier campo de texto de Internet en una posible vía de acceso. Además, Log4j solía encontrarse en varias capas de profundidad dentro de los árboles de dependencias, por lo que muchos equipos dedicaron los primeros días simplemente a averiguar si lo utilizaban. Posteriormente, los investigadores encontraron vulnerabilidades en la primera corrección (2.15.0) y en la siguiente, y los equipos siguieron actualizando hasta que la versión 2.17.1 las solucionó.
React2Shell (CVE-2025-55182)
Los componentes de servidor de React se ejecutan en el servidor y envían su salida al navegador, y el navegador puede llamar directamente a funciones del servidor. React transmite todo esto en un formato denominado «Flight». Cuando llega una solicitud «Flight», el servidor la vuelve a convertir en objetos, un paso denominado «deserialización», y React confiaba en la estructura de esos datos. Un atacante podía manipular una solicitud para que llegara a funciones integradas de Node.js, como `child_process.execSync`, y ejecutar comandos de shell sin necesidad de iniciar sesión.
Las aplicaciones quedaban expuestas aunque nunca hubieran definido una función de servidor, ya que el código de decodificación de Flight se ejecuta siempre que se admiten componentes de servidor. Las configuraciones predeterminadas de React 19 eran vulnerables, y la CISA, la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE. UU., la añadió a su lista de vulnerabilidades explotadas en ataques reales. Un error posterior, el CVE-2025-67779, eludió el parche original, por lo que los equipos tuvieron que actualizar por segunda vez.
¿Por qué siguen apareciendo errores de 2Shell?
PHP2Shell, Node2Shell y HTTP2Shell aparecieron la misma semana que se detectaron fallos críticos en eMudhra, GitLab, NGINX, Plex, Railway y OpenCode. Cualquiera de ellos podría haber sido la noticia más importante del año en materia de seguridad, y la gente empezó a llamarlo «Octubre Negro».
La IA está detectando los errores antiguos más rápido
PHP ha sido la base de gran parte de la web durante tres décadas, por lo que la mayoría de la gente daba por hecho que sus fallos graves se habían detectado hacía mucho tiempo; sin embargo, PHP2Shell permaneció oculto en el código durante 14 años. Tras la revelación, dirigimos la herramienta « análisis de código con IA » de Aikido al código fuente de PHP y esta volvió a detectar PHP2Shell en cuestión de horas. Si una herramienta de defensa puede encontrar un fallo como este en una tarde, las herramientas de los atacantes no tardarán en hacerlo.
Cómo te ayuda « Aikido Security » a gestionar las vulnerabilidades de 2Shell
Aikido Security« análisis de composición de software » (SCA) y escaneo de imágenes de contenedores muestran qué repositorios e imágenes siguen ejecutando un entorno de ejecución o una biblioteca vulnerables, incluidos los paquetes Brotli transitivos.
Si no puedes actualizar de inmediato, las imágenes de Aikido parcheadas y gratuitas disponibles en el registro público de Amazon Elastic Container Registry de Aikido cubren las versiones de PHP desde la 5.5 hasta la 8.5, excepto la 8.0 y la 8.1 por el momento. En las líneas de lanzamiento que no cuentan con una corrección del proveedor original, se retroaplican las correcciones para que puedas mantener tu número de versión. En cuanto a la vulnerabilidad de Brotli, las imágenes parcheadas de Node.js y Ubuntu de Aikido te permiten seguir utilizando tu versión actual en plataformas que no cuentan con una corrección del proveedor, incluidas Node.js 18 y 20.
La herramienta gratuita PHP2Shell comprueba una URL pública y te indica su estado, desde «vulnerable» hasta «totalmente actualizada».
{{walkthrough}}
