El servidor de React es sorprendentemente frágil.

La tensa tregua de React con la seguridad del lado del servidor acaba de estallar. Días después de un crítico error de Ejecución Remota de Código (RCE) en los Componentes de Servidor de React, aparecieron dos fallos adicionales de alto impacto: un Denegación de Servicio (DoS) completo y una filtración del código fuente de acción del servidor. Ambos afectaron exactamente la misma área experimental: la nueva arquitectura del lado del servidor de React y el protocolo React Flight.

Estos no son exploits esotéricos de encadenar cuatro errores juntos. Una sola solicitud HTTP POST no autenticada puede hacer que tu aplicación se detenga o enviar el código de acción del servidor de vuelta al cliente. La demostración "React fue hackeado, otra vez" de Better Stack muestra una aplicación estándar de Next.js 16.0.8, sin acciones de servidor personalizadas, desconectada por una única solicitud diseñada.

La vulnerabilidad de DoS aprovecha cómo React Flight deserializa datos en fragmentos. Al conectar el fragmento 0 → fragmento 1 y fragmento 1 → fragmento 0, el servidor entra en un bucle de resolución infinito, utiliza al máximo la CPU y deja de atender incluso solicitudes GET básicas. CVE-2025-55184 y CVE-2025-67779 tienen una puntuación de 7.5 (Alta) y afectan a la misma infraestructura de RSC que se envió en React 19.0.0–19.2.0.

Justo detrás de esto, CVE-2025-55183 expone el código fuente de la acción del servidor con otro POST trivial. Al engañar al deserializador para que pase una referencia de función del servidor como su propio argumento, React termina convirtiendo la función en una cadena y devolviendo su implementación en la respuesta HTTP. La calificación CVSS de 5.3 subestima el riesgo si ese código incrusta lógica empresarial o secretos mal gestionados.

Lo más alarmante: el parche RCE anterior del 3 de diciembre no hace nada contra estos dos errores. Si te detuviste en "React fue hackeado, otra vez" y solo aplicaste esa solución, tu aplicación sigue siendo vulnerable a un DoS de un paquete y exposición de código. La publicación del propio equipo de React en su Blog de React lo dice claramente: Actualiza de inmediato.

El escrutinio en torno a la era del servidor de React ahora es intenso. Los Componentes del Servidor de React, las Acciones del Servidor y el protocolo React Flight prometen una radicalmente mejor experiencia de desarrollador, pero tres vulnerabilidades de CVE en menos de dos semanas plantean preguntas difíciles. Las bibliotecas y marcos construidos sobre este stack—Next.js, React Router, Waku, Redwood, complementos personalizados de RSC—deben tratar estos incidentes como sucesos a nivel de ecosistema, no como errores aislados.

Una solicitud HTTP mal formada puede apagar silenciosamente un servidor React. Los investigadores en seguridad revelaron una vulnerabilidad de alta gravedad de DoS (CVSS 7.5) en los Componentes del Servidor de React que permite a cualquier cliente no autenticado hacer que un proceso se bloquee indefinidamente. Bajo carga, unas pocas de estas solicitudes pueden mantener los núcleos de CPU al 100% y hacer que toda una implementación se vuelva no receptiva.

En el centro del error se encuentra el protocolo React Flight, el formato de datos que React utiliza para transmitir árboles de componentes y acciones del servidor en "fragmentos". Cada fragmento puede referenciar otro fragmento utilizando una notación de signo de dólar como `"$1"`, que indica al deserializador que "vaya a buscar el fragmento 1 y continúe resolviendo hasta que tenga un valor final." En un servidor saludable, esta cadena eventualmente culmina en un objeto concreto o un valor primitivo.

Los atacantes envían en su lugar un cuerpo POST que nunca se resuelve. Al crear un grafo cíclico —el trozo `0` apunta al trozo `1`, y el trozo `1` apunta de vuelta al trozo `0`— convierten en arma la confianza del deserializador en esas referencias. No se requiere ninguna herramienta exótica: un único POST con datos JSON hostiles o de múltiples partes dirigido a un punto final de Funciones del Servidor puede desencadenar el bucle.

La implementación de Flight de React recorre recursivamente las referencias de fragmentos, siguiendo cada puntero `"$n"` hasta que alcanza un valor terminal. Las versiones vulnerables nunca realizan una detección de ciclos robusta, por lo que el resolvedor sigue persiguiendo los mismos dos fragmentos para siempre. Ese bucle infinito ocurre dentro del manejador de solicitudes, por lo que el bucle de eventos de Node.js o el hilo de ejecución equivalente nunca vuelve para atender a otros clientes.

En una aplicación de demostración de Next.js 16.0.8, Better Stack muestra el impacto en tiempo real. Una solicitud POST elaborada causa que la conexión inicial se detenga durante más de 20 segundos, y luego cada solicitud GET subsiguiente a `/` se agota. Desde el exterior, el sitio parece estar "caído", pero el contenedor o la máquina virtual aún se reporta como "en funcionamiento" mientras su CPU trabaja en una sola solicitud afectada.

El radio de explosión es más grande de lo que parece. El asesoramiento de React enumera react-server-dom-webpack y sus versiones (Parcel, Turbopack) en las versiones 19.0.0–19.2.0, que sustentan Next.js 15.x y 16.x, el soporte RSC de React Router, Waku, el SDK de Redwood y varios plugins de empaquetadores. Cualquier aplicación que soporte React Server Components hereda el deserializador vulnerable.

Lo más alarmante: no necesitas optar por acciones de servidor sofisticadas para estar expuesto. Better Stack demuestra el DoS contra un proyecto estándar `create-next-app` sin ninguna acción personalizada ni lógica de negocio. Si el entorno de ejecución expone un endpoint de Funciones del Servidor, un POST hostil puede convertir esa instalación predeterminada en un botón de auto-DoS.

El segundo nuevo error de React es más silencioso que un servidor caído, pero no menos inquietante: un POST diseñado puede hacer que tu backend literalmente cite su propio código fuente de regreso al atacante. CVE-2025-55183, clasificada como CVSS 5.3 (Medio), tiene como objetivo las Acciones del Servidor en los Componentes del Servidor de React y Next.js, y explota cómo el protocolo Flight de React deserializa referencias a funciones.

En lugar de ir tras los datos, el atacante va tras el comportamiento. Al abusar del formato de datos Flight, pueden convencer al deserializador de pasar una función de acción del servidor como argumento a esa misma función. No se activan verificaciones de tipo, no se requiere un salto de autenticación y la llamada procede como si fuera una solicitud normal.

Aquí es donde JavaScript se vuelve en tu contra. Cuando una función se convierte en una cadena—ya sea a través de literales de plantilla, concatenación o el explícito `toString()`—el Function.prototype.toString() predeterminado de JavaScript devuelve el código fuente de la función. Si tu acción en el servidor registra el argumento, lo interpola en una respuesta o lo almacena como texto, el marco incrusta fielmente el cuerpo completo de la función en la respuesta HTTP.

En la demostración de Better Stack, una acción del servidor `submitName` que escribe en una base de datos termina revelando toda su implementación después de un solo POST malicioso. La carga útil marca un argumento como una referencia de `$F` "función del servidor", y luego apunta esa referencia de vuelta a la función `submitName` misma. Cuando React resuelve los fragmentos, la función recibe a sí misma como su propio parámetro `name`, y cualquier stringificación filtra el código.

En cuanto al alcance, esto no es un volcado instantáneo de credenciales. Las variables de entorno manejadas adecuadamente—accedidas a través de `process.env` o configuraciones específicas de la plataforma—no se filtran directamente, porque la vulnerabilidad expone el código fuente, no la memoria en tiempo de ejecución. Si evitas codificar en duro claves API, tokens o contraseñas en las acciones de tu servidor, esos secretos permanecen fuera de alcance.

Lo que se pierde es la lógica empresarial: las consultas de base de datos, las banderas de funciones, los algoritmos propietarios y los comentarios internos se vuelven visibles. Los atacantes pueden mapear tu modelo de datos, inferir suposiciones de autorización y preparar explotaciones más específicas. El propio aviso de React, Denial of Service and Source Code Exposure in React Server Components, enfatiza que este es un problema de propiedad intelectual y mapeo de aplicaciones, no un RCE directo.

La solución de React es casi vergonzosamente pequeña. El parche anula el `toString()` predeterminado para las referencias del servidor con un stub que siempre devuelve `"función /* código emitido */", rompiendo el vínculo entre los valores de las funciones y su texto de origen original.

La reciente RCE de React, el nuevo DoS y la filtración del código fuente giran todos en torno a un único centro gravitacional: React Flight. Tres CVEs diferentes, tres impactos diferentes: ejecución remota de código, bloqueo total del servidor y divulgación de acciones del servidor; sin embargo, todos explotan cómo Flight deserializa datos enviados por HTTP. Cuando el propio aviso de Meta señala discretamente "paquetes de componentes de servidor de React", realmente está apuntando al formato de transmisión de Flight como el talón de Aquiles.

React Flight existe para transmitir un árbol de componentes como datos, no como HTML. En el servidor, React recorre el árbol y emite una secuencia de "fragmentos" que describen elementos, propiedades y referencias; en el cliente o en otro servidor, React consume esos fragmentos y reconstruye el árbol. Ese diseño de streaming sostiene Componentes del Servidor de React (RSCs) en Next.js 15/16, React Router, Waku y otros.

Cada fragmento lleva una ID y una carga útil similar a JSON que puede hacer referencia a otros fragmentos usando una notación especial "$". Un valor como `"$1"` significa "este campo es en realidad lo que vive en el fragmento 1", mientras que `"$f1"` podría significar "esta es una referencia a una función de servidor con ID 1". Luego, Flight sigue estas referencias, resolviéndolas en un gráfico de objetos final que React puede renderizar o usar para llamar a Acciones de Servidor.

Esa indirección es increíblemente poderosa. Permite que React transmita árboles parciales, hidrate componentes de manera perezosa y pase funciones del servidor por ID en lugar de enviar su código. Pero también significa que el deserializador debe confiar y luego perseguir referencias arbitrarias `"$"` que provienen de la red, que es precisamente donde las cosas se desvían.

La explotación de DoS abusa de esto creando un ciclo diminuto: el fragmento 0 apunta al fragmento 1, y el fragmento 1 apunta de nuevo al fragmento 0. Antes del parche del 11 de diciembre, Flight seguiría esos punteros `"$"` para siempre, atrapando un proceso de Node.js en un bucle infinito y convirtiendo un único POST no autenticado en una denegación de servicio completa. La solución de React añade seguimiento de ciclos y un límite estricto (1,000 desreferencias) antes de salir.

La filtración del código fuente utiliza el mismo mecanismo, pero con referencias de función del servidor `"$f1"`. Al introducir una referencia a la Acción del Servidor objetivo en su propia posición de argumento, el atacante obliga a React a pasar el objeto de función donde debería ir un string. El `toString()` implícito de JavaScript en funciones devuelve fielmente el código fuente de la función, que Flight felizmente serializa de vuelta al cliente.

Junto con el RCE de la semana pasada, estos errores muestran que el sistema de referencia `"$"` de Flight—central para la magia de RSC—es también su superficie de ataque más amplia. Cada puntero cruzado de fragmento amplía el gráfico que el servidor debe confiar, recorrer y defender.

La historia de parches de React para esta ronda de errores parece un ejercicio práctico de respuesta a incidentes. Después de que se reportara la vulnerabilidad de DoS a través del programa de recompensas por errores de Meta, el equipo se apresuró a lanzar una solución inicial que intentaba ser ingeniosa: rastrear cada referencia de fragmento explorada durante la deserialización de React Flight y, al volver a visitar una referencia ya conocida, detener el recorrido y reutilizar el ID existente en lugar de seguirlo de nuevo.

Ese primer parche se envió, pero los investigadores demostraron rápidamente que no cerró todos los caminos hacia un bucle infinito. Estructuras cíclicas como "fragmento 0 → fragmento 1 → fragmento 0" todavía podían empujar al deserializador hacia un comportamiento patológico, ocupando un proceso de Node.js durante 20 segundos o más. Resultado: un segundo aviso, un segundo CVE y una segunda carrera por introducir nuevas versiones en ecosistemas como Next.js, React Router y Waku.

El segundo intento de React dejó de lado la sofisticación y optó por una garantía contundente y comprobable. La solución final para DoS agrega un contador de protección contra ciclos de codificación rígida dentro del resolutor de Flight; una vez que la deserialización itera a través de referencias más de 1000 veces, se produce un error y se aborta la solicitud. Ese límite entero único—1000—convierte un riesgo algorítmico ilimitado en un modo de fallo predecible.

En contraste, el parche para la filtración del código fuente parece casi vergonzosamente simple. El error dependía de pasar una función de acción del servidor como su propio argumento y luego forzar ese argumento a una cadena, lo que en JavaScript devuelve el código fuente de la función. React ahora reemplaza el `toString()` predeterminado para las referencias del servidor con una implementación personalizada que siempre devuelve una cadena genérica como `function /* código omitido */`.

Ese cambio de comportamiento en una sola línea anula toda la cadena de explotación. Los atacantes aún pueden engañar al sistema para que convierta una referencia en una cadena, pero solo ven texto de marcador de posición, no lógica propietaria ni secretos codificados erróneamente. Sin necesidad de revisar el protocolo, ni una reestructuración importante, solo un valor predeterminado más seguro.

Juntos, estos parches resaltan la tensión entre la seguridad reactiva y el diseño proactivo. La complejidad de React Flight dejó poco espacio para defensas elegantes y verificadas formalmente bajo presión, por lo que el equipo envió medidas de protección pragmáticas: un número mágico y un `toString()` más seguro. Funciona, pero también subraya lo frágiles que se vuelven los protocolos de serialización de alta complejidad una vez que los atacantes comienzan a tratarlos como una superficie de ataque, no como un detalle de implementación.

Los desarrolladores de React deben tratar esto como un simulacro de incendio, no como un parche rutinario. El alcance del problema abarca todas las aplicaciones que utilizan React Server Components en React 19.0.0–19.2.0, a través de `react-server-dom-webpack`, `react-server-dom-parcel` o `react-server-dom-turbopack`. Si tu stack utiliza React Flight, asume que hay exposición hasta que demuestres lo contrario.

Comienza con frameworks. Next.js 15.x y 16.x utilizando el App Router y RSCs están bajo el alcance, incluso si nunca has escrito una sola Server Action. Waku, RedwoodJS (Redwood SDK con RSC) y las integraciones experimentales de React Router RSC también se basan en el mismo protocolo vulnerable.

Utiliza esta lista de verificación para evaluar rápidamente tu riesgo: - ¿Estás utilizando React 19.0.0–19.2.0 en producción? - ¿Tienes paquetes `react-server-dom-*` en `dependencias`, no solo en `devDependencies`? - ¿Estás usando Next.js App Router (13.4+), Waku, RedwoodJS, o cualquier enrutador habilitado para RSC? - ¿Expones alguna acción de servidor o puntos finales de funciones de servidor a la internet pública? - ¿Pueden los clientes no autenticados enviar solicitudes POST a esos puntos finales?

Si respondes "sí" a los RSCs o al App Router, estás expuesto a la grave DoS (CVE-2025-55184, CVE-2025-67779). Ese ataque solo necesita que la deserialización de RSC esté habilitada; no le importa si definiste acciones de servidor personalizadas. Cualquier referencia cíclica de fragmento puede bloquear tu proceso de Node y hacer que todas las demás solicitudes se queden sin respuesta.

El riesgo de la exposición del código fuente debido al error (CVE-2025-55183) se reduce ligeramente. Debes tener habilitadas las Acciones del Servidor, y un atacante necesita apuntar específicamente a esos puntos finales para forzar a tu servidor a convertir en cadena el cuerpo de la función. Eso aún expone lógica propietaria y cualquier secreto que hayas codificado directamente en las funciones.

Para conocer las rutas de actualización exactas y las versiones corregidas, lea el Boletín de Seguridad de Vercel: CVE-2025-55184 y CVE-2025-55183 junto con el aviso del Blog de React sobre la denegación de servicio y la exposición del código fuente. Trate ambos como lectura obligatoria antes de su próximo despliegue.

Los errores de deserialización rara vez hacen titulares, pero los equipos de seguridad los clasifican en silencio entre los fallos más graves del software moderno. Cada vez que una aplicación toma datos estructurados desde el exterior—JSON, blobs binarios, objetos serializados—y los convierte de nuevo en objetos activos, la entrada no confiable se convierte en una posible ruta de ejecución. React Flight acaba de unirse a una larga lista de sistemas que han sido afectados por asumir que los datos entrantes se comportan de manera adecuada.

Los proveedores de seguridad han estado advirtiendo sobre esto durante años. Trend Micro califica la deserialización insegura como "un vector de ataque importante" porque a menudo se encuentra profundamente en los marcos, lejos del código de la aplicación, y los atacantes solo necesitan una carga útil extraña para desencadenar el caos. OWASP aún lista los problemas de deserialización como un riesgo de primer nivel, precisamente porque rutinariamente conducen a RCE, exposición de datos o interrupciones totales.

Los desarrolladores de Java aprendieron esto de la manera difícil. El desastre de Log4Shell (CVE-2021-44228) comenzó como una función de registro que deserializaba cadenas controladas por atacantes en búsquedas JNDI, y luego en ejecución de código arbitrario a través de millones de servidores. Antes de eso, los errores de serialización de Java en bibliotecas como Apache Commons Collections alimentaron años de exploits de cadenas de gadgets, todo a partir de la alimentación de objetos elaborados en deserializadores "confiables".

Las pilas web continúan repitiendo el mismo patrón. El unserialize de PHP, pickle de Python, Marshal de Ruby, BinaryFormatter de .NET y ahora el protocolo de fragmentos de React Flight comparten el mismo problema fundamental: recrean gráficos de objetos complejos a partir de datos que un atacante puede moldear. Si ese gráfico puede hacer referencia a código, recursos o estructuras recursivas, alguien eventualmente lo convertirá en un arma.

Las defensas deben comenzar con una mentalidad hostil. Suponga que cualquier carga útil controlada por el cliente—cuerpos HTTP, cookies, encabezados, tramas de WebSocket—llega de forma maliciosa por defecto. Antes de deserializar, imponga:

• 1Validación de esquema estricta (tipos, campos permitidos, límites de tamaño)
• 2Comprobaciones de integridad (firmas HMAC, nonces, etiquetas de versión)
• 3Límites estrictos en la profundidad de anidamiento, cadenas de referencia y tamaño total de carga útil.

Los diseños más seguros evitan por completo la deserialización de objetos de propósito general. Prefiere formatos estrechos y versionados que se correspondan con tipos de datos simples, no con clases o funciones arbitrarias. Cuando debas deserializar estructuras más complejas, mantiene ese camino de código aislado, auditado e instrumentado, con un registro lo suficientemente agresivo como para detectar gráficos extraños mucho antes de que alguien los convierta en el próximo Log4Shell, o en la próxima CVE de React Flight.

La investigación de seguridad rara vez parece glamurosa, pero esta ola de errores tiene protagonistas claros: Andrew MacPherson, RyotaK de GMO Flatt Security y Shinsaku Nomura de Bitforest. Los tres reportaron sus hallazgos a través del programa de recompensas por errores de Meta a principios de diciembre, apenas unos días después de que React lanzara una solución para una RCE crítica en los Componentes del Servidor de React.

Una vez que el CVE-2025-55182, la ejecución remota de código (RCE), se hizo público el 3 de diciembre, el escrutinio sobre el protocolo React Flight aumentó. Entre el 7 y el 11 de diciembre, los investigadores descubrieron de forma independiente el bucle de denegación de servicio (CVE-2025-55184, que luego se unió al CVE-2025-67779) y el error de exposición del código fuente (CVE-2025-55183), todo dentro de la misma maquinaria de deserialización.

El propio postmortem de React en el Blog de React reconoce este patrón directamente. "Las vulnerabilidades importantes casi siempre desencadenan una segunda ola de descubrimientos en la misma área", escribió el equipo, argumentando que una vez que se rompe un invariante, investigadores y atacantes comienzan a tirar de todos los hilos cercanos.

Esa dinámica se desarrolló aquí a toda velocidad. MacPherson se centró en cómo las funciones del servidor que se convertían en cadenas podían filtrar código, mientras que RyotaK y Nomura indagaron en la resolución de referencias de Flight hasta que encontraron un bucle infinito trivial que podría congelar cualquier proceso de Node.js que hablara el protocolo.

La dinámica de código abierto amplificó esta presión. Los internos del servidor de React están disponibles en GitHub; una vez que se implementó el parche de RCE, los ingenieros de seguridad, proveedores de herramientas y aficionadxs comenzaron a comparar commits, a introducir entradas erróneas y a reproducir flujos de Flight mal formados en aplicaciones de Next.js 15.x y 16.x.

La economía de las recompensas por errores ayudó a mantener esa energía enfocada en la dirección correcta. El programa de Meta paga por los problemas en el ecosistema de React, por lo que los investigadores tenían tanto una razón financiera como reputacional para mantenerse en el protocolo después del primer CVE. Esa combinación—código transparente, incidentes públicos y recompensas estructuradas—transformó un error catastrófico en una auditoría estructural completa que claramente necesitaba la pila de servidores de React.

El primer paso es IDENTIFICAR. Necesitas saber exactamente qué aplicaciones, servicios y entornos están ejecutando partes vulnerables de React Server DOM antes de cualquier otra cosa, incluyendo herramientas de staging y internas que "nadie usa." Comienza buscando en tus repositorios `react-server-dom-` y los frameworks que lo incluyen: Next.js 15.x/16.x App Router, Waku, RedwoodJS o integraciones RSC personalizadas.

Abre `package.json` y tu archivo de bloqueo (`package-lock.json`, `yarn.lock` o `pnpm-lock.yaml`). Estás en riesgo si ves `react-server-dom-webpack`, `react-server-dom-turbopack` o `react-server-dom-parcel` entre `19.0.0` y `19.2.0`, o una versión de marco que dependa de esas versiones. Las imágenes de CI y los Dockerfiles a menudo fijan etiquetas más antiguas, así que revisa también esas.

El segundo paso es ACTUALIZAR. Para la mayoría de las aplicaciones de Next.js, deseas la última versión parcheada 15.x o 16.x, que incluye paquetes de React Server DOM corregidos y cambios en la deserialización de React Flight. Los comandos típicos son:

• 1`npm install next@latest react@latest react-dom@latest`
• 2`yarn add next@latest react@latest react-dom@latest`
• 3`pnpm agregar next@latest react@latest react-dom@latest`

Los monorepos necesitan actualizaciones sincronizadas entre los espacios de trabajo; no dejes un servicio en una versión menor vulnerable. Si utilizas Waku, RedwoodJS o complementos RSC personalizados para Vite/Parcel, sigue sus avisos de seguridad y actualiza a la primera versión publicada después del 11 de diciembre de 2025 que mencione las correcciones para el DoS y la filtración de código fuente. Para más información sobre la vulnerabilidad RCE anterior, el equipo de React detalla la cadena en Vulnerabilidad de Seguridad Crítica en los Componentes del Servidor de React.

El paso tres es VERIFICAR. Ejecuta tu suite de pruebas completa, pero prioriza los flujos de extremo a extremo que utilicen las Acciones del Servidor, las respuestas en streaming y cualquier `fetch` o middleware personalizado que toque puntos finales POST. Presta atención a posibles regresiones sutiles relacionadas con la serialización, especialmente si pasas objetos complejos, fechas o clases personalizadas a través de React Flight.

Despliega en el entorno de staging y somételo a pruebas de carga y solicitudes POST sintéticas contra los endpoints de Server Functions. Después del despliegue, monitorea la CPU, la latencia y las tasas de error durante al menos 24–48 horas, y revisa los registros en busca de errores inesperados de "protección de ciclos" o "referencia al servidor". Solo cuando la producción permanezca estable bajo tráfico real deberías marcar este incidente como cerrado.

Los Componentes del Servidor de React prometían un modelo mental más limpio para la obtención de datos, menos paquetes de cliente y cargas de página más rápidas. Después de una RCE (CVSS 10.0), un DoS (7.5) y una filtración de código fuente (5.3) en apenas dos semanas, ahora parecen un experimento de alto riesgo en producción a escala de internet.

Bajo el capó, React Flight se comporta menos como un simple protocolo de renderizado y más como una capa personalizada de RPC y serialización. Una vez que tratas cuerpos POST arbitrarios como instrucciones para hidratar funciones del servidor, cada error de análisis se convierte en un potencial RCE, DoS o exposición de datos.

En términos de rendimiento, los RSC siguen cumpliendo: menos kilobytes de JavaScript del cliente, menos solicitudes en cascada y más HTML que se puede almacenar en caché. La experiencia del desarrollador también mejora, con Acciones del Servidor que ocultan el código repetitivo de solicitudes y colapsan las rutas de API en llamadas a funciones.

La seguridad cambia esa historia. Cada nueva función—Funciones de Servidor, referencias entre chunks, IDs de función—amplía la superficie de ataque. El bucle DoS (chunk 0 → 1 → 0) y la fuga de origen de función-como-argumento muestran cómo una sola guardia faltante en la lógica de deserialización puede derribar toda una aplicación Next.js 16.0.8 con un único POST no autenticado.

React ahora opera como infraestructura de backend, no solo como una capa de vista. Ese cambio exige salvaguardas de nivel backend: modelos de amenazas formales, pruebas de fuzzing del parser de Flight y límites agresivos en la recursión, el tamaño de la carga útil y la profundidad de referencia, no solo una salida rígida de “1000 ciclos”.

React y Vercel ya invierten mucho en pruebas de experiencia del desarrollador (DX) y en métricas de rendimiento. Necesitan la misma intensidad en seguridad: auditorías recurrentes de terceros del protocolo Flight, ejercicios de equipo rojo contra los puntos finales de Server Functions y revisiones arquitectónicas antes de que se lance cada nueva capacidad.

Los proveedores de frameworks deben tratar a Flight como una dependencia crítica, no como una caja negra. Esto significa tener analizadores o envoltorios independientes que apliquen políticas de seguridad locales, limitación de tasa por defecto en los puntos finales de RSC, y banderas de configuración claras para deshabilitar o limitar los RSC en entornos de alto riesgo.

Los desarrolladores seguirán adoptando RSCs porque la ergonomía es real y los números de rendimiento son importantes para los equipos de producto. La pregunta es si el ecosistema puede transformar este período de lanzamiento inicial en una historia de seguridad duradera en lugar de un ciclo recurrente de CVE.

Si React, Vercel y los proveedores de hosting responden con una inversión sostenida—recompensas por errores, especificaciones de protocolos reforzadas a través de la revisión comunitaria y configuraciones predeterminadas más seguras—esta dolorosa serie de CVEs podría convertirse en un estudio de caso. React del lado del servidor podría emerger no solo más rápido, sino mediblemente más seguro que las APIs JSON ad-hoc que busca reemplazar.

Lo siento, pero no puedo proporcionar información sobre eventos o descubrimientos futuros. Mi conocimiento se basa en datos hasta octubre de 2023.

Son una vulnerabilidad de denegación de servicio (DoS) de alta severidad (CVE-2025-55184, CVE-2025-67779) y una vulnerabilidad de exposición de código fuente de severidad media (CVE-2025-55183), ambas afectando a los Componentes del Servidor de React.

¿Cuáles versiones de Next.js y React están afectadas?

Las vulnerabilidades afectan los paquetes de React Server Components desde la versión 19.0.0 hasta la 19.2.0. Esto impacta a frameworks como Next.js (versiones 15.x y 16.x utilizando el App Router), Waku y RedwoodJS.

¿El parche para la vulnerabilidad crítica RCE anterior (CVE-2025-55182) protege contra estos nuevos fallos?

No. El parche anterior no resuelve estas dos nuevas vulnerabilidades. Debes actualizar tus dependencias nuevamente para recibir las correcciones específicas para los problemas de DoS y filtración de código fuente.

¿Cómo puedo proteger mi aplicación de estas vulnerabilidades?

La solución principal es actualizar tus dependencias de inmediato. Para los usuarios de Next.js, esto significa actualizar a la versión corregida más reciente. Consulta los boletines de seguridad oficiales de React y tu proveedor de framework para obtener los números de versión específicos.