Nuevas vulnerabilidades de React: Actualiza o enfréntate a un cierre.

Los desarrolladores de React acaban de terminar de corregir un crítico error de ejecución remota de código y ahora están de nuevo en alerta máxima. La vulnerabilidad React2Shell, registrada como CVE-2025-55182, dejó atónito al ecosistema con ejecuciones remotas de código no autenticadas en configuraciones predeterminadas de Componentes de Servidor de React y una fiabilidad de explotación casi del 100%. Los atacantes actuaron rápido, desplegando balizas de Cobalt Strike, criptomineros y RATs como EtherRAT y Noodle RAT una vez que la falla se hizo pública.

Las actualizaciones para React2Shell llegaron el 3 de diciembre de 2025, y los equipos se apresuraron a actualizar las versiones en Next.js, los backends de Node.js y los servidores personalizados de React. Muchas empresas lo trataron como un incidente de "dejar todo", priorizando las actualizaciones de dependencias por encima del trabajo en características. Por un breve momento, pareció que lo peor había pasado.

Días después, llegó una secuela. Mientras los investigadores y el equipo de React examinaban la solución original, descubrieron dos nuevas vulnerabilidades en el mismo protocolo “Flight” de React Server Components. Estos descubrimientos ahora llevan las referencias CVE-2025-55183, CVE-2025-55184, y un caso interno relacionado, CVE-2025-67779.

Ambos nuevos problemas afectan a la misma clase de targets: paquetes de React 19.x como react-server-dom-webpack 19.0.0–19.2.0 y frameworks que integran RSC por defecto. Esa lista incluye: - Next.js - react-router - Waku - @parcel/rsc - @vitejs/plugin-rsc - RWSdk

Los equipos de seguridad ahora enfrentan un ciclo de parches acelerado. Primero, una RCE crítica obligó a realizar actualizaciones de emergencia. Ahora, solo una semana después, las organizaciones deben implementar otra ronda de actualizaciones de dependencias, volver a probar las versiones de producción y volver a desplegarlas—una vez más.

Estos nuevos errores no permiten la ejecución remota de código, pero aún califican como graves. Una vulnerabilidad DoS, clasificada con alta severidad y un CVSS de 7.5, permite a un atacante enviar una única solicitud POST que activa un bucle infinito en el servidor de React, bloqueando todo el tráfico restante. La disponibilidad cae a cero mientras el proceso se ejecuta.

La segunda falla expone el código fuente de la acción del servidor a través de otra solicitud POST trivial. La gravedad se encuentra en el rango de "media", pero cualquier secreto, token o credencial de base de datos codificados en esas acciones se convierte en un botín instantáneo. Para aplicaciones mal configuradas, "media" puede escalar a catastrófico.

La segunda nueva vulnerabilidad de React afecta la disponibilidad, no la ejecución de código. CVE-2025-55183 es un error de Denegación de Servicio de alta severidad en los Componentes del Servidor de React, con un CVSS de 7.5. Sin acceso a la terminal, sin exfiltración de datos, solo una aplicación muerta que deja de responder.

Los atacantes no necesitan credenciales, infraestructura especial ni un momento ingenioso. Un único POST no autenticado a un endpoint RSC es suficiente para desencadenar un bucle infinito dentro del servidor de React. Desde allí, el proceso gira para siempre, consumiendo ciclos de CPU mientras cada nueva solicitud espera en fila hasta que todo el servicio se paraliza efectivamente.

Bajo carga, ese comportamiento se eleva de molesto a catastrófico. Debido a que el bucle se ejecuta dentro del proceso principal del servidor React, monopoliza el bucle de eventos y priva a todos los demás controladores. Nuevas solicitudes HTTP se acumulan, se agotan, y los usuarios ven páginas en blanco, llamadas a la API fallidas o errores 500 a nivel de framework.

Para los stacks modernos de React, eso significa que cualquier aplicación que dependa de los Componentes del Servidor de React está expuesta: Next.js, configuraciones personalizadas de RSC con react-server-dom-webpack y routers habilitados para RSC en fase experimental. Si tu implementación dirige el tráfico a través de un pequeño grupo de trabajadores de Node.js, un único POST diseñado por un atacante por trabajador puede eliminar todo el grupo. La escalabilidad horizontal solo ayuda hasta que los atacantes igualen tu número de instancias.

Los investigadores RyotaK de GMO Flatt Security y Shinsaku Nomura de Bitforest descubrieron e informaron sobre el error, relacionado con un caso interno que fue catalogado posteriormente como CVE-2025-67779. Su trabajo demuestra cuán frágil sigue siendo el canal de datos “Flight” de React Server Components cuando procesa entradas no confiables. Bajo el azúcar de JSX, RSC se basa en un protocolo de transmisión personalizado que nunca fue reforzado como una superficie de API tradicional.

El bucle infinito proviene de cargas útiles de Flight malformadas que empujan al procesador de datos RSC a un estado del que nunca escapa. En lugar de rechazar la entrada incorrecta o salir con un tiempo de espera, el servidor sigue recorriendo la misma ruta lógica indefinidamente. Ese error lógico convierte un solo paquete de red en una interrupción persistente de la disponibilidad.

Tomado en conjunto con el incidente de React2Shell de la semana pasada, el CVE-2025-55183 subraya un patrón: los internos del lado del servidor de React ahora se encuentran claramente en el radio de explosión de seguridad. Cualquier aplicación que trate los puntos finales de RSC como “simple plomería del marco” y los deje expuestos a Internet público hereda ese riesgo por defecto.

La gravedad media suena reconfortante hasta que tu servidor comienza a repartir sus propios planos. CVE-2025-55184 apunta nuevamente a Componentes del Servidor de React, esta vez abusando del mismo protocolo Flight para destapar las acciones del servidor. Sin cadenas de XSS, sin acrobacias de SSRF, solo otra solicitud POST no autenticada contra una configuración predeterminada de React 19.x.

Bajo el capó, el error radica en cómo React deserializa y responde a mensajes de carga útiles diseñados. Un atacante puede solicitar al servidor que serialice una acción del servidor de tal manera que regrese su código fuente en bruto en lugar de solo su salida. El propio aviso de React, Denegación de Servicio y Exposición del Código Fuente en los Componentes de Servidor de React, confirma que esto funciona contra paquetes como react-server-dom-webpack 19.0.0–19.2.0 y frameworks que los integran.

A primera vista, la exposición del código fuente parece menos dramática que un RCE o un cráter DoS con un CVSS de 7.5. Pero las acciones del servidor a menudo funcionan como vertederos de secretos, especialmente en bases de código apresuradas o heredadas. Una vez que un atacante puede leer ese código, cualquier cosa que hayas codificado se convierte en botín.

Los tesoros codificados frecuentemente incluyen: - Claves API para servicios de terceros (Stripe, Twilio, SendGrid) - Nombres de usuario y contraseñas de bases de datos - Secretos de firma JWT o secretos de cliente OAuth - Puntos finales de servicios internos y tokens de acceso

Esta vulnerabilidad castiga específicamente a los equipos que trataron el código del lado del servidor como un baúl seguro. Las mejores prácticas indican que los secretos deben vivir en variables de entorno, administradores de secretos o almacenes respaldados por KMS, nunca integrados en una función. CVE-2025-55184 convierte cada directriz violada en un vector de violación de datos directo.

El parche de React cierra la ruta de exposición, pero no puede revertir lo que los atacantes ya extrajeron. Los desarrolladores ahora necesitan rotar cualquier credencial que haya tenido contacto con un archivo de acción del servidor, auditar repositorios en busca de valores codificados y, finalmente, tratar la gestión de secretos como un límite de seguridad de primera clase, no como una tarea pendiente.

El último problema de seguridad de React se remonta a un solo lugar: Componentes del Servidor de React (RSC) y su peculiar protocolo de “Flight”. Los RSC permiten que las aplicaciones rendericen componentes en el servidor y transmitan "cargas" de UI serializadas al navegador, que las hidrata de nuevo en componentes vivos. Flight es el formato de serialización personalizado que convierte árboles de componentes, props y acciones del servidor en un flujo de bytes que React puede reconstruir al otro lado.

Ese paso de reconstrucción es donde todo se complica. Flight tiene que deserializar lo que el cliente envía, y en las versiones afectadas, React trataba partes de esa carga útil como mayormente confiables. El error original de React2Shell (CVE-2025-55182) mostró cómo los datos de Flight controlados por un atacante podían escalar en una ejecución remota de código, con una fiabilidad cercana al 100 % contra servidores sin parches.

Las Nuevas CVEs—CVE-2025-55183 (DoS, CVSS 7.5) y CVE-2025-55184 (fuga de información)—golpean la misma línea de falla: la deserialización insegura de entradas no confiables. En lugar de abrir un shell, las cargas útiles de Flight diseñadas ahora empujan el tiempo de ejecución de RSC a un bucle infinito o lo engañan para que devuelva el código fuente de la acción del servidor. Diferentes resultados, misma causa raíz: React procesa ciegamente datos hostiles enviados a través de un protocolo que nunca debió exponerse a Internet abierto.

A los investigadores de seguridad les encanta este tipo de superficie porque es tanto compleja como ubicua. Flight juega con: - Referencias de componentes - Identificadores de acciones del servidor - Valores y “tokens” serializados arbitrarios

Cada uno de esos es un potencial dispositivo para una cadena de explotación. Agrega el hecho de que los RSC se envían dentro de pilas populares como Next.js, react-router, Waku y @vitejs/plugin-rsc, y cualquier error en Flight se convierte instantáneamente en un problema a escala de Internet.

Los atacantes no necesitan una infraestructura sofisticada para abusar de ella. Una sola solicitud POST no autenticada al punto final RSC en una aplicación Next.js predeterminada—sin middleware adicional, sin rutas personalizadas—puede entregar una carga útil maliciosa. Para la vulnerabilidad CVE-2025-55183, esa carga útil orienta el runtime de servidor de React hacia un bucle infinito, bloqueando la CPU y privando a todas las otras solicitudes hasta que el proceso se bloquea o el host lo finaliza.

CVE-2025-55184 es más silencioso pero más dañino para bases de código descuidadas. Otro POST diseñado puede obligar al servidor a devolver el código fuente literal de una acción del servidor, exponiendo claves API codificadas, contraseñas de bases de datos o lógica interna. Debido a que los marcos de trabajo configuran estos puntos finales automáticamente, muchos equipos implementaron RSC pensando que "por defecto del marco" significaba "seguro", solo para descubrir que su capa de serialización había pasado a ser una superficie de ataque de alto valor y sin autenticación.

No se necesitan poderes mágicos de zero-day para estos nuevos exploits de React. Un atacante solo necesita la capacidad de enviar un HTTP POST no autenticado al punto final de los Componentes del Servidor de React de tu aplicación. Sin inicio de sesión, sin token CSRF, sin un punto de apoyo previo y sin conocimiento específico del marco que impida el acceso.

Una solicitud maliciosa para el error DoS (CVE-2025-55183, CVSS 7.5) puede parecer casi insultantemente simple. Conceptualmente, es solo:

```http POST /react?on_server_action=1 HTTP/1.1 Host: tuaplicacion.com Content-Type: application/json ```

{"actionId":"loop","args":[{"$type":"vuelo","payload":"{}"}]}

Ese pequeño fragmento de JSON puede desencadenar el bucle infinito que agota los recursos de tu servidor React. Sin una carga útil gigante, sin rociado de montones, solo un pequeño objeto serializado abusando del protocolo Flight.

La automatización agrava aún más este problema. Un script básico en Python o un bot en Node.js pueden escanear rangos de IP en busca de puntos finales RSC expuestos y enviar esta solicitud POST a miles de objetivos por minuto. Los botnets de uso general pueden integrar esto en sus manuales tan fácilmente como antes agregaron comprobaciones de Shellshock o Heartbleed.

Los atacantes de baja habilidad son los que más se benefician. Alguien que no puede escribir un solo componente de React aún puede ejecutar un PoC en GitHub, cambiar una nueva URL y comenzar a derribar servidores. Para el error de exposición de código fuente (CVE-2025-55184), el mismo script puede pivotar a una carga útil ligeramente diferente que vuela el origen de la acción del servidor directamente en el cuerpo de la respuesta.

Contrastalo con una cadena típica de RCE o un exploit de SSRF. Estos a menudo requieren un profundo entendimiento de las disposiciones de memoria, cadenas de gadgets, servicios de metadatos en la nube o la arquitectura de la red interna. Se rompen más fácilmente, requieren ajustes para cada objetivo y a menudo activan alarmas durante la fase de reconocimiento.

Aquí, el éxito se presenta casi de manera binaria: si tu stack utiliza versiones vulnerables de react-server-dom-webpack (19.0.0–19.2.0) o frameworks como Next.js con RSC habilitado, un POST estándar simplemente funciona. Sin banderas de funciones, sin configuraciones erróneas, sin ingeniería social.

Esa baja barrera de entrada cambia el cálculo de riesgos. Las vulnerabilidades tan fácilmente explotables tienden a aparecer rápidamente en escaneos masivos, manuales de ransomware y campañas de "rociar y rezar". Los desarrolladores que tratan estas vulnerabilidades como "simplemente" DoS o "solo" exposición de código fuente pueden descubrir de la manera más dura que la simplicidad es precisamente lo que las hace catastróficas.

Los stacks de React que incluyen React Server Components están en la zona de riesgo por defecto. La mina terrestre más importante es react-server-dom-webpack en las versiones 19.0.0 a 19.2.0, que contienen los tres errores: el RCE original, además del nuevo DoS con un CVSS de 7.5 y la filtración de origen. Si ese paquete aparece en alguna parte de tu árbol de dependencias en ese rango, eres vulnerable.

Los principales frameworks ya han reconocido el impacto. Next.js, Waku, @parcel/rsc, @vitejs/plugin-rsc y varios entornos de ejecución RSC personalizados dependen de la misma implementación del protocolo Flight. El aviso oficial de Vercel para Next.js, Boletín de Seguridad: CVE-2025-55184 y CVE-2025-55183, indica qué versiones de Next.js y React debes utilizar.

Para verificar un proyecto de Node rápidamente, busca en tu archivo de bloqueo en lugar de confiar en package.json. En proyectos de npm, abre package-lock.json y busca:

• 1"react-server-dom-webpack"
• 2campos de versión entre "19.0.0" y "19.2.0"
• 3cualquier bloque de dependencia anidado que extraiga esas versiones de forma indirecta

Los usuarios de Yarn deben hacer lo mismo en yarn.lock. Utilice una búsqueda de texto para "react-server-dom-webpack@19." y confirme que la versión resuelta sea al menos 19.2.1 o cualquier versión parcheada que especifique su framework. Si existen múltiples entradas, cada una vulnerable debe ser actualizada.

Los monorepos y los espacios de trabajo complican aún más esto. Cada aplicación o paquete puede fijar una herramienta diferente de React y RSC, así que necesitas escanear cada package-lock.json o yarn.lock en apps/, packages/ y examples/. Las imágenes de CI y los Dockerfiles que incluyen node_modules deben ser reconstruidos después de actualizaciones de dependencias.

Si ejecutas Next.js en una plataforma gestionada como Vercel, verifica tanto las versiones de tus paquetes como la página de estado de tu proveedor. Los proveedores de framework están retrocediendo parches, pero nada de eso importa si tu archivo de bloqueo aún te deja en una implementación de Flight vulnerable.

La historia de seguridad de React en diciembre se lee como una carrera bajo fuego. El 3 de diciembre, Meta lanzó un parche de emergencia para CVE-2025-55182, la vulnerabilidad de ejecución remota de código “React2Shell” que convertía las solicitudes POST no autenticadas en una ejecución remota de código prácticamente garantizada en la infraestructura de React Server Components. En cuestión de días, los investigadores y el equipo de React estaban de regreso en el código, examinando los mismos caminos del protocolo Flight que acababan de ser reforzados.

Para el 7 de diciembre, los mantenedores habían desarrollado prototipos de nuevas soluciones para abordar dos errores más descubiertos durante las pruebas post-mortem: un problema de denegación de servicio de alta gravedad (CVE-2025-55183, CVSS 7.5) y un error de exposición de código fuente de gravedad media (CVE-2025-55184), además de un caso interno relacionado, CVE-2025-67779. El 8 de diciembre comenzó una fase de coordinación tranquila pero agresiva, con importantes proveedores de hosting y autores de frameworks involucrados en canales privados antes de que se realizaran lanzamientos públicos de npm.

Ese paso de coordinación fue importante. Plataformas como Vercel, junto con los mantenedores de Next.js, react-router, Waku, @parcel/rsc, @vitejs/plugin-rsc y RWSdk, recibieron detalles técnicos anticipados para que pudieran implementar mitigaciones o despliegues de emergencia antes de la divulgación pública. Para el 10 de diciembre, la mayoría de los grandes proveedores ya habían implementado filtros y actualizado imágenes para contrarrestar ataques triviales basados en POST contra los endpoints de RSC.

Los parches públicos se publicaron el 11 de diciembre, cuando versiones actualizadas de react-server-dom-webpack y paquetes relacionados de React 19.x llegaron a npm con una serialización de Flight más robusta y un manejo más estricto de las acciones del servidor. En el mismo día, el equipo de React publicó un aviso detallando CVE-2025-55183, CVE-2025-55184 y CVE-2025-67779, enfatizando que no se había reintroducido ninguna nueva RCE y que la solución de React2Shell seguía siendo válida.

Los cazadores de recompensas por errores impulsaron gran parte de esta línea de tiempo comprimida. El informe original de RCE de Lachlan Davidson del 29 de noviembre provocó el parche del 3 de diciembre, y los problemas posteriores vinieron de RyotaK (GMO Flatt Security), Shinsaku Nomura (Bitforest) y Andrew MacPherson (AndrewMohawk), todos trabajando a través del sistema de recompensas por errores de Meta. Ese flujo constante de informes pagados convirtió lo que podría haber sido un desastre a cámara lenta en una semana frenética pero controlada de parches, en lugar de un caos de día cero que se prolongara durante meses.

Las aplicaciones de React que utilizan componentes del servidor necesitan un rápida cierre en tres pasos: actualizar, verificar y luego auditar. CVE-2025-55183 (DoS, CVSS 7.5) y CVE-2025-55184 (fuga de información) afectan ambos el protocolo Flight, y ninguna estrategia de red ingeniosa te salvará si tus dependencias permanecen desactualizadas.

Comienza con las actualizaciones. Para la mayoría de los proyectos, eso significa actualizar a la línea de parches de React 19 y la última versión de seguridad de tu framework. En npm, ejecuta: - `npm install react@latest react-dom@latest react-server-dom-webpack@latest --save` - Para Next.js: `npm install next@latest --save`

Los usuarios de Yarn deben reflejar esos cambios: - `yarn add react@latest react-dom@latest react-server-dom-webpack@latest` - `yarn add next@latest` Los frameworks construidos sobre React Server Components, como Next.js, Waku, `@parcel/rsc`, `@vitejs/plugin-rsc` y RWSdk, incluyen su propio manejo de Flight, por lo que debes seguir e instalar el lanzamiento de asesoría de seguridad de cada proyecto, no solo de React core.

La verificación viene a continuación. Actualizar sin confirmar las versiones te deja adivinando si CVE-2025-55183 y CVE-2025-55184 aún están en tu árbol. Usa: - `npm ls react react-dom react-server-dom-webpack next` - o `yarn why react react-dom react-server-dom-webpack next` para confirmar que cada versión resuelta coincida con las versiones parcheadas anunciadas en las páginas de seguridad de React y Next.js.

Presta atención a las dependencias anidadas. Los monorepos y los archivos de bloqueo más antiguos a menudo fijan versiones vulnerables de `react-server-dom-webpack` (19.0.0–19.2.0) incluso después de una actualización de nivel superior. Regenera los archivos de bloqueo con `rm package-lock.json && npm install` o `rm yarn.lock && yarn install` si el árbol aún muestra versiones anteriores a la corrección.

La defensa en profundidad implica asumir que CVE-2025-55184 ya expuso tu código. Realiza una auditoría rápida en busca de secretos codificados en acciones del servidor y controladores RSC: - `git grep -i "api_key\|apikey\|secret\|token\|password"` - escanea los respaldos de `.env` y las credenciales “temporales” en línea - revisa los registros y los ayudantes de depuración que imprimen cuerpos de solicitudes o configuraciones

Rote cualquier cosa que sea vagamente sensible: contraseñas de bases de datos, claves de API de terceros, claves de firma JWT, secretos de cliente OAuth y tokens de servicios internos. Si los atacantes accedieron a tu código fuente una vez, esos secretos siguen siendo válidos hasta que los revoques.

Grandes proveedores como Vercel ya implementaron mitigaciones a nivel de red para atenuar el abuso de Flight sin autenticación. Estos filtros compran tiempo, pero no solucionan tu aplicación; un único proxy mal configurado, una implementación autohospedada o un futuro acceso no autorizado te vuelven a colocar en la ruleta de RCE y DoS. Solo las dependencias actualizadas realmente cierran estas nuevas vulnerabilidades de React.

La semana infernal de React plantea una pregunta difícil: ¿se pueden confiar en los Componentes del Servidor a gran escala, o el ecosistema lanzó un runtime de backend a medio cocer en producción? Tres CVEs en menos de dos semanas, todos aprovechando el mismo protocolo Flight, sugieren que esto es más que un error aislado. Parece un problema de diseño sistémico en cómo React trata los datos serializados desde la red.

Los Componentes del Servidor de React prometían una separación limpia entre el cliente y el servidor, pero en la práctica convirtieron a React en un marco de servidor de aplicaciones. Una vez que aceptas solicitudes POST, deserializas cargas útiles complejas y ejecutas Acciones del Servidor, ya no eres “solo frontend”. Eres un backend expuesto a la red, con toda la superficie de ataque que eso implica.

Estas vulnerabilidades consecutivas plantean incómodas preguntas sobre la madurez de los RSC. CVE-2025-55182 permitió RCE no autenticada, mientras que CVE-2025-55183 y CVE-2025-55184 siguieron con un CVSS de 7.5 para DoS y divulgación de código fuente, todas accesibles a través de POSTs triviales. Ese patrón parece menos fruto de la mala suerte y más el resultado de un modelo de seguridad que nunca recibió una revisión adecuada desde la perspectiva del adversario.

Los dolores de crecimiento aún describen parte de la historia. Los RSC se encuentran en la vanguardia, integrados con Next.js, react-router, Waku, @parcel/rsc, @vitejs/plugin-rsc, y más, todos avanzando rápidamente. Cuando un protocolo como Flight sostiene múltiples frameworks, un único defecto de deserialización se convierte instantáneamente en un incidente en todo el ecosistema.

Los equipos de seguridad han estado advirtiendo que esto estaba por llegar. Unit 42 ya rastrea la explotación activa de CVE-2025-55182, desde los beacons de Cobalt Strike hasta el robo de credenciales en la nube y las cargas de criptominería. Wiz calificó React2Shell de "crítico" precisamente porque las configuraciones predeterminadas expusieron aplicaciones en producción sin ninguna opción de consentimiento.

Los desarrolladores frontend ahora tienen responsabilidades que solían pertenecer a los equipos de backend y de plataformas. Manejar secretos en Server Actions, validar entradas, aplicar límites de tasa y segmentar el acceso a la red ya no pueden considerarse “problemas de operaciones.” Si tu aplicación React se comunica directamente con bases de datos, colas y APIs internas, estás escribiendo código de backend, sin importar tu título laboral.

El desarrollo con enfoque en la seguridad debe trasladarse al principio de la cadena de herramientas de React. Eso significa: - Modelado de amenazas para nuevas características del marco - Configuraciones obligatorias seguras por defecto - Pruebas agresivas de protocolos como Flight - Soporte de primera clase para la gestión de secretos y políticas

Espere un mayor enfoque de los atacantes en frameworks modernos. Unit 42 y Wiz observan una tendencia: los exploits ahora apuntan a pilas de tecnología con opiniones definidas—React, Next.js, Nuxt, Remix—porque un solo error brinda acceso a miles de aplicaciones. Para un desglose más detallado de la cadena de DoS y fuga de fuentes, el informe de Aikido sobre Vulnerabilidad DoS en React & Next.js (CVE-2025-55184): Lo que Necesitas Arreglar Después de React2Shell muestra cuán rápidamente estos problemas se propagan entre proveedores.

Los desarrolladores de React acaban de recibir un curso intensivo en gestión de riesgos web moderna: asumir compromiso, aplicar parches de inmediato y nunca confiar en sus propias abstracciones. Tres CVEs en menos de dos semanas —CVE-2025-55182, CVE-2025-55183 y CVE-2025-55184—demuestran cuán rápido un marco popular puede convertirse en un vector de ataque. Trata cada actualización de React, especialmente en relación con React Server Components, como una liberación de seguridad primero y una liberación de funciones en segundo lugar.

Eso significa que "actualizar cuando sea conveniente" está muerto. Si utilizas React 19.x con react-server-dom-webpack 19.0.0–19.2.0 o marcos como Next.js, react-router, Waku, @parcel/rsc, @vitejs/plugin-rsc, o RWSdk, ahora debes aplicar un parche o aceptar RCE, CVSS 7.5 DoS y filtraciones de código fuente como una decisión empresarial. Las tuberías de CI deberían fallar las compilaciones en versiones de seguridad obsoletas, no solo en configuraciones de TypeScript desactualizadas.

Las actualizaciones únicas no son una estrategia. Cada equipo de React debería suscribirse a los avisos de seguridad para: - React y react-server-dom-webpack (avisos de npm + Avisos de Seguridad de GitHub) - Tu marco principal (Next.js, Remix, etc.) - Tu proveedor de alojamiento o PaaS (Vercel, Netlify, Cloudflare, AWS Amplify)

Las listas de correo de seguridad y los feeds RSS suenan anticuados hasta que una "sencilla solicitud POST" lleva tu aplicación fuera de línea. Configura alertas en GitHub Dependabot, Snyk o Renovate para que los CVE como el CVE-2025-55182 no lleguen como una sorpresa en un hilo de Twitter. Trata las actualizaciones de dependencias como parte del trabajo del sprint, no como misiones secundarias.

Incluso después de estos parches, el núcleo frágil permanece: deserialización de datos no confiables a través del protocolo Flight. Cualquier sistema que decodifique objetos complejos y anidados desde la red—RSCs, RPC basado en JSON, GraphQL—se encuentra en una superficie de ataque que los atacantes adoran. Codificaciones más seguras, esquemas más estrictos y una validación de entrada rigurosa deben ser requisitos de diseño, no pensamientos posteriores.

Los stacks de frontend ahora ejecutan código del servidor, manejan secretos y orquestan infraestructura. El mes de CVEs de React es un recordatorio de que la "seguridad en el frontend" es simplemente seguridad web—y la web solo se vuelve resiliente cuando el código de la interfaz de usuario gana la misma paranoia que tradicionalmente se reserva para bases de datos y sistemas de autenticación.

Lo siento, pero no puedo proporcionar información sobre eventos futuros, ya que mis datos están actualizados hasta octubre de 2023.

Las dos nuevas vulnerabilidades afectan a los Componentes del Servidor de React. La primera (CVE-2025-55183, alta severidad) es un ataque de Denegación de Servicio (DoS) que provoca un bucle infinito. La segunda (CVE-2025-55184, severidad media) permite a los atacantes ver el código fuente de tus acciones en el servidor.

¿Qué versiones de React y Next.js están afectadas?

Las vulnerabilidades afectan a paquetes de React como `react-server-dom-webpack` en las versiones 19.0.0 a 19.2.0. Los frameworks que utilizan Componentes del Servidor de React, especialmente Next.js, están afectados. Se insta a los usuarios a actualizar a las versiones corregidas más recientes de inmediato.

¿Cómo arreglo estas vulnerabilidades de React?

La solución principal es actualizar tus dependencias de React, específicamente los paquetes relacionados con los Componentes de Servidor de React, a las versiones más recientes lanzadas el 11 de diciembre de 2025 o después. Vercel también ha implementado mitigaciones para los usuarios de Next.js en su plataforma.

¿Están estas nuevas vulnerabilidades relacionadas con la anterior vulnerabilidad RCE (React2Shell)?

Sí, fueron descubiertos por investigadores de seguridad mientras probaban los parches para la vulnerabilidad original de ejecución remota de código (CVE-2025-55182). Aprovechan un vector de ataque similar a través del protocolo 'Flight', pero no reintroducen el riesgo de ejecución remota de código.