Después de React2Shell: tres límites de seguridad que toda revisión de componentes de servidor necesita

El error costoso: tratar un parche como si fuera toda la evaluación

React2Shell, CVE-2025-55182, se reveló el 3 de diciembre de 2025 como ejecución remota de código sin autenticación en React Server Components. React atribuye el descubrimiento a Lachlan Davidson. El aviso oficial clasifica el problema como deserialización insegura. [1, 6]

Para un responsable de producto, la pregunta útil es si el servicio desplegado puede convertir de forma segura una solicitud externa en trabajo en el servidor. Este artículo propone una revisión de tres límites: valores permitidos, operaciones permitidas y consumo de recursos permitido. Es un análisis editorial de los registros públicos enlazados, verificados el 4 de octubre de 2026, no la afirmación de haber descubierto o reproducido estas vulnerabilidades.

Determine la exposición a partir del despliegue, no del nombre del producto

Inventaríe la integración de RSC y los paquetes react-server-dom-webpack, react-server-dom-parcel o react-server-dom-turbopack realmente resueltos. Una aplicación React sin ejecución en el servidor ni una integración compatible con RSC queda fuera del alcance del aviso original. No tener ninguna Server Function escrita explícitamente no demuestra, por sí solo, que un despliegue de RSC esté libre de este problema. [1]

Registre la imagen de producción o el identificador de despliegue, la resolución de dependencias, la configuración del framework y los manejadores de solicitudes accesibles. Una copia de trabajo de un desarrollador ya parcheada no demuestra qué ejecuta un despliegue antiguo, un entorno de preview o una imagen de rollback. Separe «el paquete está presente», «la versión vulnerable está presente» y «la ruta de código relevante es alcanzable»: son tres afirmaciones distintas, y cada una necesita su propia evidencia.

Primer límite: los bytes solo deben convertirse en valores permitidos

La deserialización es más que comprobar si una solicitud se parece a JSON. Un decodificador puede reconstruir referencias, interpretar tipos o resolver valores diferidos. La pregunta de revisión es qué significados puede hacer que el servidor construya un atacante antes de que la aplicación haya validado la solicitud. Rastree esa transformación a través de la integración real del framework, en lugar de asumir que el manejador de negocio recibe primitivos inofensivos.

El modelo siguiente es una ayuda para la revisión, no el grafo de llamadas interno de React ni una receta de explotación. Identifique los tipos de valores aceptados, el manejo de referencias y las rutas de error. Pruebe entradas malformadas y ambiguas en un entorno aislado usando los puntos de entrada documentados. Una pequeña solicitud rechazada no debería dejar un estado parcialmente reconstruido que otra solicitud pueda reutilizar. Esa última condición es un invariante que hay que investigar en su producto, no una afirmación sobre estos CVE.

HTTP input
  -> [1] decode into permitted values
  -> [2] authorize the requested operation
  -> [3] execute within an explicit work budget
  -> produce a permitted response

Review invariants:
  malformed input -> bounded rejection
  unauthorized operation -> no state change
  excessive work -> bounded termination
  error response -> no sensitive implementation data

Segundo límite: que una función se pueda llamar no la convierte en una operación autorizada

La documentación de React sobre Server Functions explica cómo las llamadas del cliente se convierten en solicitudes de red que invocan código del servidor. Esa capacidad de transporte no proporciona los permisos a nivel de objeto de su producto. [5] Para una función que modifica una factura, el servidor debe determinar quién llama, a qué tenant pertenece la factura y si ese principal puede realizar precisamente esa transición de estado.

Use una matriz de permisos con un visitante anónimo, un miembro del tenant correcto, un miembro de un tenant distinto y una cuenta de solo lectura. Compruebe tanto la respuesta devuelta como el estado almacenado. Rechazar una solicitud después de que la actualización ya se haya producido es un fallo del límite de autorización, aunque el estado HTTP parezca tranquilizador. Repita las comprobaciones para llamadas indirectas, operaciones por lotes e identificadores alternativos que su aplicación realmente acepte.

Tercer límite: una entrada válida puede seguir exigiendo un trabajo inaceptable

CVE-2026-23864, revelada el 26 de enero de 2026, cubre casos adicionales de denegación de servicio en RSC. Los mantenedores describen resultados que incluyen uso excesivo de CPU, agotamiento de memoria y caídas de proceso. [3] React afirma que estos problemas posteriores no reabrieron la vulnerabilidad de ejecución remota de código de React2Shell. Distinga las propiedades que aborda cada parche. [2]

Un límite de tamaño de solicitud mide los bytes entrantes; no acota directamente el trabajo que esos bytes desencadenan. Revise la expansión de referencias, la resolución repetida, las llamadas posteriores y el comportamiento de cancelación donde existan esos mecanismos. Elija límites realistas de CPU, memoria, concurrencia y finalización para el producto. Un timeout solo es útil si el trabajo subyacente realmente se detiene. Use un entorno de pruebas y umbrales de interrupción predefinidos; agotar deliberadamente un proceso de producción no es una prueba de aceptación útil.

Inspeccione la respuesta de producción, incluido lo que contiene el bundle

CVE-2025-55183 se refiere a la exposición de código fuente en determinadas configuraciones de Server Functions. El aviso describe como en riesgo los secretos codificados dentro del código expuesto; no establece una fuga general de valores de variables de entorno en tiempo de ejecución a través de este fallo en concreto. El inlining del empaquetador puede afectar al código fuente visible en el artefacto de producción. [4, 2]

Revise los valores devueltos, las conversiones implícitas a cadena de texto, los errores y el cuerpo compilado de la función. Use un marcador inerte en una compilación de prueba dedicada para comprobar si los detalles de implementación cruzan el límite de la respuesta. Un resultado negativo para un marcador es una evidencia limitada, no la prueba de que todas las rutas de respuesta son seguras. Separe esta comprobación de la investigación de un incidente de RCE, donde un proceso comprometido puede tener un acceso mucho más amplio a los secretos.

Construya un registro de límites que sus desarrolladores puedan repetir

El registro siguiente conecta una ruta y la compilación desplegada con un principal, una clase de entrada, un resultado esperado y la evidencia observada. Es una plantilla de informe propuesta. Rellénela con mediciones reales, en lugar de describir un ataque teórico como un hallazgo confirmado. Para cada operación rechazada, incluya la ausencia de cambio de estado; para cada prueba de recursos, incluya cuándo cesó el trabajo y qué límites se aplicaron.

El aviso de enero de 2026 enumera 19.0.4, 19.1.5 y 19.2.4 como correcciones para sus paquetes RSC cubiertos. Son umbrales históricos de parche, no una recomendación de congelar un despliegue en esas versiones ni la afirmación de que no exista un aviso posterior. [3] Seleccione una versión del framework actualmente soportada y parcheada, reconstruya y vuelva a desplegar, y después verifique los paquetes resueltos y el comportamiento relevante en ese artefacto exacto.

route_id | deployed_build | package_versions
principal | tenant | object | requested_operation
input_class | expected_result | observed_result
cpu_time | peak_memory | downstream_calls
state_before | state_after | reviewer | evidence_ref

Qué debería ofrecer al responsable de producto una evaluación útil

Pida una decisión clara sobre la exposición, las evidencias de dependencias y despliegue que la respaldan, y conclusiones separadas sobre decodificación, permisos, uso de recursos y fuga en las respuestas. Cada hallazgo debería indicar sus condiciones previas, el flujo de trabajo afectado, su reproducción en el entorno acordado, el impacto práctico y los criterios de verificación. Una lista impresionante de nombres de CVE no puede sustituir esa conexión con su aplicación.

Para un encargo acotado, elija un flujo de trabajo de alto valor, como la facturación, la administración de cuentas o el acceso a datos de un tenant. Combine la revisión del código fuente con comprobaciones de comportamiento acordadas, conserve el registro de límites y vuelva a probar el despliegue corregido. La misma separación entre significado, autoridad y presupuesto de trabajo resulta útil al revisar la deserialización en Java o los analizadores nativos, aunque sus mecanismos y vulnerabilidades deben investigarse de forma independiente.