Se divulgan vulnerabilidades de DoS y exposición de código fuente en React Server Components

• Se descubrieron y divulgaron nuevas vulnerabilidades de denegación de servicio (DoS) y exposición de código fuente en React Server Components
• Estas vulnerabilidades no permiten ejecución remota de código (RCE), pero sí implican riesgo de caída del servidor o filtración de código
• Los paquetes afectados son react-server-dom-webpack, react-server-dom-parcel y react-server-dom-turbopack en las versiones 19.0.0~19.2.2; las versiones corregidas son 19.0.3, 19.1.4 y 19.2.3
• La vulnerabilidad DoS (CVE-2025-55184, CVE-2025-67779) puede provocar un bucle infinito en el servidor mediante solicitudes HTTP maliciosas, y la vulnerabilidad de exposición de código fuente (CVE-2025-55183) puede devolver parte del código de funciones del servidor
• El equipo de React recomienda actualizar de inmediato y explica que esta divulgación adicional forma parte del proceso normal del ciclo de respuesta de seguridad

---

Resumen de las nuevas vulnerabilidades divulgadas

• Investigadores de seguridad descubrieron dos vulnerabilidades adicionales mientras verificaban el parche de una vulnerabilidad crítica divulgado la semana pasada
• Las nuevas vulnerabilidades no permiten ejecución remota de código (RCE), y el parche existente de React2Shell sigue siendo válido
• Las vulnerabilidades recién divulgadas son las siguientes
  • Denegación de servicio (DoS) — CVE-2025-55184, CVE-2025-67779 (CVSS 7.5, gravedad alta)
  • Exposición de código fuente — CVE-2025-55183 (CVSS 5.3, gravedad media)
• El equipo de React recomienda actualizar de inmediato

Incompletitud del parche anterior

• El parche de las versiones 19.0.2, 19.1.3 y 19.2.2 distribuido la semana pasada fue incompleto, por lo que se requiere otra actualización
• La corrección completa está incluida en las versiones 19.0.3, 19.1.4 y 19.2.3
• Deben seguirse las instrucciones de actualización de la publicación anterior
• Se divulgarán más detalles una vez finalice la distribución del parche

Paquetes y versiones afectadas

• Las vulnerabilidades existen en los mismos paquetes y versiones que CVE-2025-55182
• Versiones afectadas: 19.0.0~19.2.2
• Paquetes afectados:
  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack
• Versiones corregidas: 19.0.3, 19.1.4, 19.2.3
• Las aplicaciones que no usan servidor o no admiten React Server Components no están afectadas

Patrón general de divulgación de vulnerabilidades posteriores

• Después de la divulgación de un CVE crítico, a menudo se encuentran vulnerabilidades posteriores durante el análisis adicional de rutas de código relacionadas
• Se menciona como ejemplo el caso en que se reportaron CVE adicionales después de Log4Shell
• Estas divulgaciones adicionales significan que la respuesta de seguridad está funcionando con normalidad

Frameworks y bundlers afectados

• Los siguientes frameworks y bundlers incluyen o dependen de los paquetes vulnerables de React
  • next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc, rwsdk
• Deben seguirse las instrucciones de actualización de la publicación anterior

Medidas de mitigación de proveedores de hosting

• Se aplicaron medidas temporales de mitigación en colaboración con varios proveedores de hosting
• Sin embargo, no debe confiarse en estas medidas y es necesario actualizar de inmediato

Instrucciones relacionadas con React Native

• Los usuarios que solo usan React Native no necesitan acciones adicionales
• En un entorno monorepo, solo es necesario actualizar los siguientes paquetes
  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack
• No es necesario actualizar react ni react-dom
• Los detalles relacionados pueden consultarse en el issue de GitHub de React Native

Gravedad alta: denegación de servicio (DoS)

• CVE-2025-55184, CVE-2025-67779, CVSS 7.5
• Si se envía una solicitud HTTP maliciosa al endpoint de funciones del servidor de React, puede producirse un bucle infinito durante la deserialización
• El proceso del servidor puede detenerse y consumir CPU de forma excesiva
• Incluso si no se implementa directamente el endpoint de funciones del servidor, una app que admita React Server Components puede ser vulnerable
• El parche distribuido hoy resuelve el problema al evitar el bucle infinito
• Como la corrección inicial fue incompleta, se complementó con una vulnerabilidad adicional (CVE-2025-67779)

Gravedad media: exposición de código fuente

• CVE-2025-55183, CVSS 5.3
• Una solicitud HTTP maliciosa puede devolver parte del código fuente de una función del servidor
• Ocurre cuando la función del servidor expone argumentos de tipo cadena de forma explícita o implícita
• En el código de ejemplo, podrían exponerse secretos hardcodeados como claves de conexión a base de datos
• El parche resuelve el problema al evitar la conversión a cadena del código fuente de funciones del servidor
• El alcance de la exposición se limita al código interno de la función del servidor, y los secretos de runtime (process.env.SECRET, etc.) no están afectados
• Es necesario verificarlo con base en el bundle de producción

Línea de tiempo

• 3 de diciembre: Andrew MacPherson reporta la exposición de código a Vercel y Meta Bug Bounty
• 4 de diciembre: RyotaK reporta la vulnerabilidad DoS
• 6 de diciembre: El equipo de React confirma ambos problemas e inicia la investigación
• 7 de diciembre: Se redacta la corrección inicial y se establece el plan de validación
• 8 de diciembre: Se notifica a proveedores de hosting y proyectos open source
• 10 de diciembre: Se aplican medidas de mitigación y se completa la validación del parche
• 11 de diciembre: Shinsaku Nomura reporta un DoS adicional, y se divulgan CVE-2025-55183, 55184 y 67779

Reportantes

• Andrew MacPherson (AndrewMohawk) — reporte de exposición de código fuente
• RyotaK (GMO Flatt Security Inc) y Shinsaku Nomura (Bitforest Co., Ltd.) — reporte de vulnerabilidades de denegación de servicio

[GN⁺]

Opiniones en Hacker News

• React Server Components (RSC) siempre se sintió incómodo
  Porque con solo ver el código JavaScript es difícil distinguir qué parte se ejecuta en el cliente y qué parte se ejecuta en el servidor
  Además, para implementar esto se necesita un mecanismo RPC de serialización profundo, que es opaco para los desarrolladores y aumenta el riesgo de vulnerabilidades de seguridad

  • En la época del pages router de NextJS, me gustaba que el límite entre el código del servidor y el del cliente fuera claro
    Pero al cambiar al app router, todo se volvió confuso. Como el código podía ejecutarse en ambos lados, objetos como Headers no siempre existían y era difícil saber qué se ejecuta y dónde
  • Cuando vi que un equipo al que me acababa de unir usaba Next, pregunté: “¿Alguien sabe cómo funciona esto?” y nadie pudo explicarlo con claridad
    Cuando React+Next funciona bien, se siente como magia, pero al trabajar en equipo el problema es que la previsibilidad desaparece cada vez más
  • Por eso soy fan de Inertia.js. Inertia.js conecta de forma natural backends MVC tradicionales como Laravel, Rails y Django con herramientas de frontend como React, Vue y Svelte
    Los roles están claros, el trabajo es simple, y creo que es la opción más segura para la mayoría de los proyectos
  • Parece que RSC y SSR se han adoptado en exceso
    Para landing pages o páginas de marketing, SSR puede ser útil, pero en apps como un dashboard SaaS común casi no aporta beneficios frente a la complejidad que añade
  • Me pregunto qué tan expuestos estarán otros frameworks (Angular, SvelteKit, Nuxt) a este tipo de vulnerabilidades
    Queda la duda de si React solo recibe más atención por su popularidad o si estructuralmente es más riesgoso

• La semana pasada estuve revisando RSC y la complejidad era demasiado alta, además de que casi no había documentación
  React dice que todavía es una función experimental, pero NextJS ya lo desplegó ampliamente
  Parece probable que aparezcan más problemas de seguridad, y el sistema de build de Next es tan complejo que hasta depurarlo resultó difícil
  El costo es demasiado alto para los beneficios que ofrece

  • Desde antes había quejas de que Next “empaqueta funciones de React que todavía no están listas para producción” como si fueran novedades de última generación
    Por eso yo también dejé Next. La carga cognitiva era demasiado alta para lo poco que ofrecía a cambio
  • React lleva mucho tiempo con problemas de falta de documentación
    No solo con RSC, sino en general: las guías claras llegaron tarde y ni siquiera reconocían oficialmente herramientas como CRA
    Recién ahora la documentación de useEffect mejoró, pero ya es demasiado tarde
    Incluso en 2025, aunque sigo usándolo en el trabajo, todavía falta documentación clara

• La idea central de un SPA era “enviar toda la app al cliente y solo intercambiar datos con el servidor”

  • Pero ahora en el mundo de C# está de moda Blazor Server
    Como en los antiguos .aspx Web Forms, cada clic e interacción se envía al servidor, y luego baja de nuevo el DOM modificado
    En la práctica, es como haber vuelto al modelo anterior, y resulta algo absurdo
  • Al final, muchos desarrolladores volvieron a entender por qué existe el renderizado del lado del servidor y regresaron a frameworks full stack como PHP, Rails o Spring
  • Pero hoy en día se usa mucho React y librerías similares para crear sitios estáticos, y eso termina siendo más lento y más complejo que una combinación simple de motor de plantillas + JS
    Da pena que se haya perdido ese “criterio para elegir la herramienta adecuada”
  • Claro, RSC no está pensado para SPA puros. Es un enfoque con otros objetivos

• En este aviso de seguridad, la frase que más me llamó la atención fue que “cuando se descubre un CVE crítico, a menudo salen a la luz vulnerabilidades relacionadas”
  Antes de explicar el alcance, el impacto o cómo mitigar el problema, parecía que intentaban justificar el CVE, y eso me inquietó

  • Pero otra persona opinó que “no era una justificación, sino simplemente una explicación sobre lo primero que la gente iba a querer saber”
  • Dijeron que ajustaron la redacción en respuesta a los comentarios → enlace al PR corregido
  • Alguien describió esto como gestión de la percepción (perception management)
    Artículo relacionado en Wikipedia
  • También hay quienes creen que en este asunto hay intereses de carrera profesional involucrados
  • Alguien más dijo: “Esto parece escrito por el equipo de marketing de Vercel”

• Hace 15 años, Opa ya había intentado algo parecido
  Separaba automáticamente el código del cliente y del servidor, e introdujo una sintaxis similar a JSX
  Pero al reforzar el análisis de seguridad, el compilador se volvió enorme, y al final quedó claro que era más importante una separación explícita que la idea de una sola app unificada
  Tal vez algún día un LLM pueda generar este tipo de código automáticamente, pero por ahora creo que una estructura simple es mejor

  • En realidad, las vulnerabilidades de RSC no se deben tanto a la división del código como al carácter dinámico del proceso de serialización/deserialización
    Se están aplicando parches para bloquear problemas como la contaminación de prototipos en JS, toString en funciones y la sobrescritura de Promise
    RSC distingue los entornos mediante validación estática con cosas como import "server-only" o import "client-only", así que a nivel estructural es un enfoque seguro
  • Hay un proyecto con una idea parecida llamado Electric Clojure → enlace
  • Como referencia, Ocsigen Eliom probó este concepto incluso antes que Opa

• React era mejor cuando originalmente era pequeño y simple, cumpliendo solo el papel de View en MVC
  Ahora tiene demasiadas funciones y da la impresión de haberse hinchado

  • Pero RSC es una librería aparte, no viene incluida en una instalación base de React
  • Si quieres volver a una versión antigua, basta con git checkout v15.0.0

• RSC nunca debió existir
  Para la mayoría de las apps basta con renderizar HTML en el servidor, y los casos donde realmente hace falta un SPA son muy pocos
  RSC solo ha aumentado la complejidad y las vulnerabilidades de seguridad

  • De acuerdo. Pero el ecosistema impulsado por bootcamps y financiamiento de VC sigue empujando en esa dirección
    Proyectos como Bun y Vercel venden la ilusión de una “utopía JS donde todo funciona perfecto”, así que parece difícil que esta tendencia desaparezca pronto

• Hace tiempo discutí con Dan Abramov en X sobre RSC
  Él decía que era una función innovadora, pero yo lo llamé una "pistola para dispararte en el pie". Al final, la realidad terminó yendo por ese camino

  • En lo personal, he creado una app con RSC y todavía me gusta este enfoque
    Pero se subestimó la posibilidad de errores a nivel de protocolo. Esta vulnerabilidad se concentra en el protocolo de serialización
    La comunidad de seguridad apenas ahora lo está examinando a fondo, así que ojalá el equipo hubiera reaccionado antes
  • Los sistemas exitosos suelen terminar convertidos en monstruos por expansión excesiva
    React pasó de ser una simple librería de renderizado a un runtime, y la complejidad explotó
  • Personalmente, no me parece que el enfoque de Dan sea tan brillante
    En cambio, creo que Vue y Vite tienen un diseño mucho más elegante → sitio personal de Evan You
  • Claro, la mayoría de las ideas terminan fracasando, así que también hay que cuidarse de una actitud puramente crítica
    A veces los intentos audaces sí terminan siendo un home run
  • También hubo un comentario de apoyo: “Quizá tú seas el que lo hace mejor”

• Si RSC es un intento de que el frontend se trague al backend, HTMX sería lo contrario
  HTMX mantiene el límite cliente-servidor, así que del lado del backend es más seguro, pero en el frontend existe riesgo de XSS

  • Pero HTMX ya resolvió el problema de XSS mediante el escape automático del motor de plantillas
    Artículo relacionado

• El equipo de Next anunció una nueva actualización de seguridad → NextJS Security Update 2025-12-11
  Afecta a las versiones 14.x, 15.x y 16.x