• Node.js
• npm

Instalación

[!NOTE] El package.json está fijado a la versión vulnerable 19.0.0.

Prueba de Concepto

1. Iniciar el servidor vulnerable

Este script configura un servidor HTTP básico que utiliza el runtime vulnerable de React para decodificar solicitudes.

2. Ejecutar el script de exploit

En una terminal separada, ejecuta el exploit. Este envía un payload Flight malicioso al servidor.

Deberías ver la salida del comando devuelta en la respuesta:

Expected Output:

Análisis

¿Por qué ocurrió la vulnerabilidad?

La función requireModule en ReactFlightDOMServerNode.js básicamente confiaba en cualquier name que enviara el cliente. Hacía moduleExports[metadata[NAME]] sin verificar si esa propiedad estaba realmente destinada a ser expuesta. Entonces, si el cliente decía "oye, quiero esta propiedad", el servidor simplemente decía "¡claro! aquí tienes, amigo".

¿Por qué es mala idea permitir que la gente acceda a cualquier propiedad?

Porque básicamente permite que cualquiera acceda a la cadena de prototipos, incluso al constructor, lo cual es súper peligroso. Si el módulo exporta una función (como module.exports = () => {}), entonces su constructor es literalmente el constructor global Function.

¿Por qué obtener el constructor Function significa RCE?

Una vez que un atacante obtiene el constructor Function, puede abusar de la característica "Bound Server Action". Enlazan una cadena que contiene JavaScript malicioso a él (básicamente convirtiéndolo en new Function("código malicioso")). Y una vez que eso se ejecuta, el servidor ejecuta cualquier código que hayan puesto.

¿Por qué React ejecutaría realmente esa función maliciosa?

Porque las Server Actions pueden ser activadas por ID. Si el atacante crea un payload con un ID de Acción que apunte a su referencia module#constructor, React lo resuelve como una acción normal y la ejecuta. Esa "acción" es en realidad su función maliciosa.

¿Por qué no se validó nada de esto?

El sistema simplemente asumía que id y name de los metadatos de la Referencia del Servidor siempre se referirían a exportaciones válidas definidas por el desarrollador. No había una verificación de seguridad como hasOwnProperty para asegurarse de que la propiedad solicitada fuera realmente una exportación real y no algo heredado de la cadena de prototipos.

¿Por qué server.js en lugar de Next.js?

Uso un server.js básico (y un webpack-runtime.js auxiliar) para configurar manualmente el runtime de React Server Components. Esto nos permite:

1. Forzar la configuración vulnerable: El exploit solo funciona si un módulo se exporta como una función (module.exports = fn)s. Un bundler real podría cambiar cómo se envuelven las exportaciones, dependiendo de su configuración sin embargo.

2. Aislar el error: Esto nos permite mostrar que el problema está dentro de react-server-dom-webpack, no en Next.js.

3. Recrear el entorno del bundler: react-server-dom-webpack asume que se está ejecutando dentro de un bundle de Webpack. Nuestro webpack-runtime.js le proporciona las globales que espera (__webpack_require__, __webpack_chunk_load__).

Esto no es simular la vulnerabilidad, es solo proporcionar a la librería el runtime mínimo necesario para que realmente funcione.

Notas

Ha habido discusión sobre "PoCs inválidos" que solo funcionan si el desarrollador expone intencionadamente cosas peligrosas como child_process.exec.

Este PoC no es uno de esos. Funciona en una configuración normal y segura.

1. La función expuesta es inofensiva La aplicación expone una función simple updateProfile que solo devuelve una cadena y nada sospechoso, sin comandos de shell.

2. El exploit escapa completamente de esa función La vulnerabilidad permite al atacante ignorar la exportación segura y saltar directamente a updateProfile.constructor, que es el constructor global Function.

3. El problema central es el acceso a la propiedad React NO debería haber permitido el acceso a .constructor. El desarrollador no tenía la intención de exponer el constructor Function, en cambio, la deserialización insegura hizo eso por ellos.

El único requisito real es que el módulo exporte una función directamente (module.exports = fn), lo cual es súper común en CommonJS y muchas configuraciones de bundler.

El Payload

El payload en exploit.js crea un mensaje React Flight con tres fragmentos:

• Chunk 0: Apunta a una Referencia de Servidor definida en el Chunk 1.
• Chunk 1: Declara la Referencia de Servidor:
  • id: "user-profile-action#constructor", que significa "dame el constructor".
  • bound: apunta al Chunk 2, que contiene los argumentos.
• Chunk 2: ["console.log('nice try, diddy!')"]: la cadena de código malicioso.

Cuando React deserializa esto:

1. Resuelve user-profile-action.
2. Lee la propiedad .constructor => obteniendo el Function global.
3. Enlaza la cadena proporcionada por el atacante a él.
4. Efectivamente ejecuta: new Function("console.log('nice try, diddy!')")

¡Y eso es RCE!

Mitigación

Actualiza inmediatamente a las versiones parcheadas:

• react-server-dom-webpack >= 19.0.1
• react-server-dom-parcel >= 19.0.1
• react-server-dom-turbopack >= 19.0.1

El parche introduce comprobaciones hasOwnProperty para prevenir el acceso a propiedades heredadas y restringe las subidas de archivos base64.

Si ejecutas este PoC contra una versión parcheada, el servidor fallará o dará error con:

Esto confirma que el exploit falló al acceder a la propiedad constructor (devolvió undefined en lugar de Function), y por lo tanto la llamada posterior a .bind falló.

Descargo de responsabilidad

Este código es solo para fines educativos y de prueba. No utilices este exploit contra sistemas que no poseas o para los que no tengas permiso explícito para probar.

Licencia

Publicado bajo DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE.