React Flight: cómo funciona la falla React2Shell y cómo proteger RSC

El protocolo Flight, utilizado por React Server Components para transmitir componentes y referencias entre el servidor y el cliente, expone una superficie de ataque más compleja que un intercambio convencional de datos. El análisis de la vulnerabilidad CVE-2025-55182, conocida como React2Shell y calificada con una puntuación CVSS de 10,0, muestra cómo una solicitud HTTP especialmente manipulada podía aprovechar la deserialización de React para alcanzar una ejecución remota de código sin autenticación.

React Server Components (RSC) modificaron la forma en que muchas aplicaciones construidas con React entregan interfaces web. En lugar de enviar todo el HTML o un objeto JSON convencional al navegador, el servidor puede transmitir una representación propia de la interfaz mediante Flight, un protocolo dividido en líneas que React procesa progresivamente.

Ese mecanismo permite cargar componentes, resolver referencias, administrar estados asincrónicos y conectar determinadas funciones del servidor con acciones invocables desde el cliente. La ventaja es una experiencia más dinámica y una transferencia eficiente de información. El problema aparece cuando la capa que reconstruye esos datos también interpreta referencias, módulos y comportamientos ejecutables sin validar de manera estricta cada elemento recibido.

El artículo técnico de Smashing Magazine sobre el protocolo React Flight analiza ese diseño desde la perspectiva de seguridad y toma como punto de partida React2Shell. La investigación sostiene que el incidente no debería entenderse solamente como un error aislado de análisis, sino como una muestra de los riesgos que aparecen cuando un formato de transporte reconstruye objetos con capacidad de activar lógica del framework.

React Flight: Qué transmite realmente Flight cuando se renderiza un componente

Las aplicaciones que utilizan el enrutador de aplicaciones de Next.js pueden mostrar respuestas con el tipo de contenido text/x-component. Ese indicador permite reconocer una carga Flight en las herramientas de red del navegador. El contenido no es un único documento JSON, sino un flujo de registros separados por saltos de línea.

Cada registro puede describirse, de forma simplificada, como un identificador numérico, una etiqueta y una carga útil. Otros registros pueden referenciar ese identificador para reutilizar información ya enviada. Una fila puede indicar un módulo que debe cargarse; otra puede representar un árbol de elementos; y otra puede establecer el contexto de ejecución asociado con el componente.

La estructura resulta útil para dividir la respuesta y resolverla a medida que llega. Sin embargo, también introduce relaciones internas que no existen en un JSON plano. Hay punteros entre fragmentos, referencias a módulos, promesas, límites de carga diferida y funciones que conectan el navegador con acciones del servidor.

Por esa razón, el contenido recibido no describe únicamente la apariencia de una página. También puede indicar qué recurso debe resolverse, qué objeto debe recuperarse y qué camino debe seguir el tiempo de ejecución de React. La diferencia es importante: un parser que interpreta instrucciones tiene una superficie de ataque superior a uno que se limita a convertir texto en datos.

El sistema de prefijos que convierte datos en referencias ejecutables

Una parte central del análisis se concentra en las cadenas que comienzan con el signo dólar. Cuando el parser encuentra una de ellas, no necesariamente la trata como texto literal. Según el prefijo, puede derivar el valor hacia una ruta de resolución específica.

El código del cliente incluye funciones como parseModelString, getChunk, reviveModel y getOutlinedModel. Estas piezas participan en la reconstrucción de fragmentos, la resolución de referencias y el cambio de estado de los bloques pendientes o ya procesados. En el lado del servidor, la gestión de respuestas para acciones del servidor se vincula con ReactFlightReplyServer.js.

Entre los prefijos descriptos en la investigación aparecen referencias a módulos, acciones del servidor, cargas diferidas, objetos internos y promesas. En particular, el mecanismo de acceso mediante dos puntos permite expresar rutas profundas, como una referencia conceptual a un campo dentro de otro objeto. El parser divide esa ruta y consulta cada propiedad de manera sucesiva.

En una aplicación normal, ese comportamiento facilita recuperar valores anidados. Desde el punto de vista de seguridad, también significa que parte del camino de acceso queda controlado por información que llega desde el flujo. Si no existe una lista permitida de propiedades ni una comprobación de pertenencia directa, el recorrido puede alcanzar propiedades heredadas del prototipo de JavaScript.

Por qué la deserialización de JavaScript también puede ser peligrosa

JavaScript suele considerarse menos expuesto que otros lenguajes frente a determinados ataques de deserialización porque JSON.parse() produce objetos de datos y no ejecuta constructores por sí mismo. Esa protección deja de ser suficiente cuando un framework agrega referencias especiales, resolución de módulos y lógica propia después del análisis inicial.

Los objetos de JavaScript heredan propiedades mediante la cadena de prototipos. Nombres como __proto__, constructor y prototype no son campos corrientes en todos los contextos: pueden conducir hacia objetos y constructores compartidos. Si una rutina de reconstrucción permite recorrerlos sin controles, el atacante puede intentar modificar el significado de operaciones posteriores o alcanzar funciones con capacidades mucho mayores.

El artículo compara este patrón con antecedentes conocidos en otros ecosistemas, como los problemas de ObjectInputStream en Java, pickle en Python, unserialize en PHP y BinaryFormatter en .NET. El paralelismo no significa que React utilice esos mecanismos, sino que ilustra una idea común: convertir una representación controlada por terceros en objetos con comportamiento puede generar cadenas de ejecución inesperadas.

También interviene la semántica de las promesas. En JavaScript, un objeto que posee una propiedad invocable llamada then puede ser tratado como un objeto entoncesable cuando se utiliza con operaciones asincrónicas. Si una estructura manipulada ingresa en una ruta de resolución que espera promesas, la propia semántica del lenguaje puede activar una función no prevista por el desarrollador.

Cómo se relacionó el recorrido de propiedades con React2Shell

La vulnerabilidad CVE-2025-55182 fue presentada como una falla crítica de ejecución remota de código no autenticada en la capa de deserialización de Flight. El punto destacado por el análisis se ubica en getOutlinedModel, que resuelve rutas profundas indicadas mediante el sistema de referencias.

El riesgo surge cuando la rutina avanza por cada segmento utilizando el objeto anterior como base, sin verificar adecuadamente que la propiedad exista en el propio objeto ni bloquear nombres reservados de la cadena de prototipos. En términos conceptuales, una referencia manipulada podía intentar desplazarse desde un objeto común hacia Object.prototype, luego hacia el constructor de objetos y finalmente hacia el constructor de funciones.

El constructor Function permite crear funciones a partir de texto y, bajo determinadas condiciones, puede producir un resultado equivalente a evaluar código. La explotación completa no depende de un único paso: requiere combinar esa posibilidad con otras capacidades legítimas de Flight, como la resolución de fragmentos, el manejo de estados y la representación de acciones del servidor.

Ese encadenamiento es precisamente lo que vuelve difícil evaluar el riesgo mirando una sola función. Un componente individual puede parecer correcto dentro del flujo normal, pero la combinación de referencias, propiedades heredadas y comportamientos asincrónicos puede producir un resultado no contemplado por el diseño original.

La información de la fuente menciona que la vulnerabilidad fue incorporada al catálogo de vulnerabilidades explotadas conocidas de la Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos. También cita investigaciones de Sysdig sobre campañas que habrían utilizado implantes sin archivos y comunicación apoyada en la cadena de bloques de Ethereum, además de un análisis de Unit 42 sobre una puerta trasera denominada KSwapDoor. Esos reportes muestran que el interés del problema no quedó limitado a pruebas de laboratorio, aunque cada organización debe verificar el alcance aplicable a sus propias versiones y dependencias.

Qué deben revisar los equipos que usan Server Actions

La primera medida es mantener React, Next.js y todas las dependencias relacionadas con RSC en versiones corregidas por sus respectivos mantenedores. La actualización debe incluir pruebas de integración, porque los cambios en el protocolo pueden afectar acciones del servidor, cargas diferidas, componentes cliente y rutas que dependen de respuestas Flight.

Las Server Actions no deberían aceptar estructuras arbitrarias. Cada entrada necesita validación mediante un esquema explícito que defina tipos, campos permitidos, longitud, formato y valores posibles. La validación debe ejecutarse en el servidor, incluso cuando el formulario o la interfaz ya hayan aplicado controles en el navegador.

También es recomendable utilizar el paquete destinado a marcar código exclusivo del servidor. Esa separación ayuda a evitar que secretos, credenciales, consultas internas o funciones privilegiadas terminen incluidos accidentalmente en módulos que pueden ser referenciados desde el cliente.

La protección contra falsificación de solicitudes entre sitios merece una revisión específica. Los valores predeterminados del framework no siempre reflejan la arquitectura concreta de una aplicación, sus dominios, sus subdominios, sus cookies y sus rutas de mutación. Las comprobaciones de origen, los tokens antifalsificación, las políticas de cookies y la validación del encabezado correspondiente deben evaluarse como un conjunto.

Los límites de las defensas complementarias

Las API de marcado de datos sensibles, como Taint, pueden reducir el riesgo de exposición accidental, pero no reemplazan la validación ni el control de autorización. Del mismo modo, un firewall de aplicaciones web puede bloquear patrones conocidos y ofrecer visibilidad sobre solicitudes anómalas, pero no necesariamente comprende todas las combinaciones válidas del protocolo Flight.

La observabilidad resulta fundamental. Los equipos deberían registrar errores de deserialización, solicitudes inusuales a endpoints de acciones, cambios inesperados en el tamaño de los flujos y respuestas que produzcan estados de error repetidos. Es importante evitar que los registros incluyan secretos, tokens o cuerpos completos de solicitudes sensibles.

El riesgo de Flight para el posicionamiento de aplicaciones Next.js

La seguridad de Flight también tiene consecuencias para la visibilidad orgánica y el rendimiento de negocios digitales. Una aplicación comprometida puede sufrir modificaciones de contenido, inyección de enlaces, redirecciones, creación de páginas no autorizadas o incorporación de código malicioso. En esos escenarios, el problema deja de ser exclusivamente técnico: puede afectar la indexación, la reputación del dominio, la confianza de los usuarios y la continuidad de las ventas.

Los sitios construidos con Next.js y componentes de servidor deben auditar qué rutas utilizan Server Actions, qué información atraviesa Flight y qué permisos tiene el proceso que ejecuta la aplicación. Reducir privilegios, separar servicios, proteger variables de entorno y mantener controles de integridad sobre los archivos desplegados limita el alcance de un incidente.

Para proyectos administrados con WordPress que incorporan servicios React, paneles externos o experiencias de comercio electrónico desacopladas, la revisión debe abarcar ambos lados de la arquitectura. Una capa de contenido segura no compensa un frontend vulnerable, y un frontend actualizado tampoco elimina riesgos en complementos, API o integraciones que aceptan solicitudes de mutación.

La vulnerabilidad analizada deja una enseñanza concreta: los equipos no deben considerar Flight como un simple formato interno imposible de alcanzar. Cada endpoint que procesa respuestas, acciones o referencias debe tratarse como una interfaz que recibe datos potencialmente manipulados. La actualización urgente, la validación de esquemas, la defensa contra solicitudes cruzadas y el monitoreo continuo forman una base razonable para reducir la exposición mientras evoluciona el ecosistema de React Server Components.