Tiempo de lectura: 5 minutos
Portada del artículo CVE-2025-55182: React2Shell de React a ejecución remota

Explicación técnica

React2shell es una vulnerabilidad crítica que afecta a aplicaciones basadas en React. Esta vulnerabilidad afecta al uso del lado servidor de React.js. Registrada como CVE-2025-55182, afecta a distintas librerías de React 19.x concretamente a las siguientes versiones:

  • react-server-dom-webpack: 19.0.0, 19.1.0, 19.1.1, 19.2.0
  • react-server-dom-parcel: 19.0.0, 19.1.0, 19.1.1, 19.2.0
  • react-server-dom-turbopack: 19.0.0, 19.1.0, 19.1.1, 19.2.0

y a Next.js 15.x/16.x si este usa App Route. Esta vulnerabilidad RCE pre-autenticación fue reportada por Lachlan Davidson. Este artículo trataremos esta vulnerabilidad a través de un laboratorio publicado recientemente por Albert Corzo, aka YZ9YT.

Wiz Research ha informado que el 39% de los entornos cloud contienen instancias vulnerables de React y Next.js que se ven afectadas por esta vulnerabilidad, los equipos que desarrollen aplicaciones con estos frameworks deberán actuar de inmediato si no quieren ver sus entornos de producción afectados.

Muchos servicios populares dependen de estas tecnologías y podrían estar en riesgo si no se aplican los parches necesarios; los atacantes podrían comprometer servidores que alojan aplicaciones ampliamente utilizadas, afectando así a millones de usuarios. Cabe destacar que si una aplicación no implementa los endpoints de React Server Functions, pero sí soporta Server Components, también puede ser vulnerable.

Flujo de ataque

React2Shell surge a partir de una deserialización insegura de cargas RSC procesadas por Server Function Endpoints expuestos vía HTTP.
Debido a deficiencias en los mecanismos de validación e integridad durante el procesamiento de dichas cargas, un actor no autenticado puede enviar solicitudes HTTP malformadas que son aceptadas como válidas.

React procede entonces a deserializar el contenido suministrado, interpretando datos controlados externamente como código ejecutable, lo que deriva en la ejecución de JavaScript en el contexto del servidor y con los privilegios del proceso afectado.

Esquema del flujo de ataque de React2Shell
Esquema del flujo de ataque de React2Shell

Prueba de concepto

Para validar la vulnerabilidad descrita se ha utilizado un laboratorio controlado, concretamente https://github.com/yz9yt/React2Shell-CTF, creado por Albert Corzo. Este entorno permite reproducir el comportamiento vulnerable de forma segura y aislada.

El servicio web expuesto por el laboratorio se encuentra accesible en el puerto 5555, desde donde se inicia la prueba de concepto.

Login servicio web expuesto

En este caso el objetivo del ataque es lograr Ejecución Remota de Código (RCE) en el servidor. Para ello, lo primero que haremos será analizar la aplicación y sus componentes. En este caso, la aplicación utiliza una versión vulnerable de una librería que permite una deserialización insegura.

La vulnerabilidad reside en cómo el servidor maneja el campo _response dentro de un payload JSON. Si conseguimos inyectar una propiedad _prefix, el servidor la ejecutará como código. Para explotar este comportamiento, será necesario construir una petición multipart/form-data.

Estructura JSON

Para enviar las peticiones utilizaremos curl o Burp Suite; no obstante, para hacer más sencillo y directo el desarrollo del PoC, en este caso usaremos curl. El primer objetivo será conseguir que el servidor ejecute algo verificable. Para ello podríamos utilizar un cálculo matemático, un echo, o algún comando del sistema como whoami, id o ls.

Además de ejecutar el script, necesitaremos que el servidor devuelva el resultado de la ejecución. Para lograrlo, añadiremos un error controlado que incluya la salida del comando, con la que podremos visualizar si se ha ejecutado en la respuesta del servidor.

Script de JS

Una vez teniendo la estructura del script, lo adaptaremos para poder utilizarlo dentro de una petición web mediante curl. Para ello, será necesaria una petición multipart/form-data válida.

Comando curl con petición y script de JS

Una vez enviada la petición, el servidor procesa y ejecuta el código inyectado. Como resultado, la respuesta del servidor contiene la salida del comando ejecutado, lo que confirma que la ejecución remota se ha realizado correctamente.

Respuesta del servidor

Una vez confirmada la ejecución de comandos, el impacto de la vulnerabilidad nos permite ir más allá y obtener una reverse shell remota. Básicamente, un atacante podría tomar el control total del sistema, ejecutar comandos de forma interactiva y realizar tareas de post-explotación. Tales como escalar privilegios, pivotar hacia otros sistemas de la red interna o mantener persistencia.

La obtención de una shell demuestra que la vulnerabilidad no se limita a una prueba puntual y que podría derivar en un compromiso completo de la infraestructura. En la siguiente imagen se muestra una sesión activa obtenida desde el sistema vulnerable, confirmando el impacto real y crítico de la vulnerabilidad.

Sesión activa obtenida mediante reverse shell

En entornos reales, la obtención de una reverse shell puede verse limitada por egress filtering, ejecución en contenedores sin privilegios o restricciones de red. Incluso sin una shell interactiva, la ejecución de comandos puntuales ya supone un compromiso crítico.

Mitigaciones/Playbook

  • Se debe actualizar React y todos los frameworks afectados, incluyendo Next.js, a la última versión parcheada.
  • Todas las aplicaciones usando React Server Components deberían reconstruirse y redesplegarse para asegurar el uso de las librerías parcheadas.
  • Los equipos de seguridad deberán revisar los logs de servidores y aplicaciones en busca de indicios de ejecución sospechosa de comandos de PowerShell o shell, en particular los que coincidan con patrones de explotación conocidos.
  • Monitoreo constante de conexiones salientes a direcciones IP maliciosas y/o la detección de Cobalt Strike, Snowlight, Vshell u otras herramientas de post-explotación deberían activar los procedimientos de respuesta ante incidentes.
  • Los monitoreos de red deberían incluir inspección para peticiones HTTP POST con headers next-action o rsc-action-id y/o cuerpos de solicitud anómalos.
  • El monitoreo de host debe centrarse en la creación inesperada de procesos, escritura de archivos en /tmp/ y la ejecución de comandos de enumeración o robo de credenciales.

Agradecimientos y video

Gracias a Albert Corzo por la creación del laboratorio que ha hecho mucho más sencillo desarrollar este artículo.

El laboratorio ha servido como entorno controlado para validar el comportamiento descrito, permitiendo centrar el análisis en el impacto y las implicaciones de seguridad más allá del reto CTF en sí.

Referencias