El 3 de diciembre se conoció la eliminación coordinada de la vulnerabilidad crítica CVE-2025-55182 (CVSSv3 — 10). Esta vulnerabilidad se detectó en componentes de servidor React (RSC), así como en varios proyectos y frameworks derivados: Next.js, React Router RSC preview, Redwood SDK, Waku y los plugins RSC Vite y Parcel.
Esta vulnerabilidad permite a cualquier atacante no autenticado enviar una solicitud a un servidor vulnerable y ejecutar código arbitrario. Considerando que decenas de millones de sitios web, incluyendo Airbnb y Netflix, se basan en React y Next.js, y que se encontraron versiones vulnerables de estos componentes en aproximadamente el 39% de las infraestructuras en la nube, la magnitud de la explotación podría ser muy grave.
Es necesario tomar medidas inmediatas para proteger sus servicios en línea. Inicialmente se creó un CVE-2025-66478 separado para la vulnerabilidad Next.js, pero se consideró un duplicado, por lo que el defecto Next.js también se incluye en CVE-2025-55182 .
React es una de las librerías JavaScript más usadas para construir interfaces web. Con la llegada de React Server Components (RSC) (que empezaron a tomar fuerza desde React 18), parte del renderizado deja de ocurrir en el navegador y pasa al servidor.
En la práctica, tu página puede “pedirle” al servidor que ejecute lógica de React, reciba el resultado y lo inserte ya listo en la respuesta. ¿Cuál es la ventaja de esto? Sitios más rápidos, porque el navegador no tiene que cargar tanto JavaScript innecesario.
RSC, además, separa la app en dos mundos: componentes de servidor y componentes de cliente. Los del servidor pueden hacer tareas “sensibles” (consultas a bases de datos, acceso a secretos, cálculos pesados), mientras que los del cliente se quedan con la parte interactiva en el equipo del usuario. Para que esa ida y vuelta sea ágil, existe Flight, un protocolo ligero sobre HTTP que mueve información serializada entre cliente y servidor.
¿Dónde entra el riesgo? En cómo se procesan esas solicitudes Flight, específicamente en una deserialización insegura (cuando el servidor “desempaqueta” datos y los convierte en estructuras internas sin validar lo suficiente). Ahí es donde vive la CVE-2025-55182.
Se reportó como vulnerable un conjunto de versiones de React Server Components (incluyendo paquetes como react-server-dom-parcel, react-server-dom-turbopack y react-server-dom-webpack) y también varias versiones de Next.js asociadas a esas implementaciones.
Lo más preocupante es el escenario de explotación: un atacante podría mandar una petición HTTP simple a un servidor expuesto y, antes incluso de autenticarse, disparar la ejecución de un proceso con privilegios del runtime de React en el servidor. En otras palabras: si el endpoint está accesible y la versión es vulnerable, el golpe puede ser directo.
Aunque en ciertos momentos no había evidencia pública concluyente de explotación masiva, especialistas en ciberseguridad han advertido que el abuso es totalmente viable y podría escalar rápido. En reportes técnicos se mencionó incluso que algunas pruebas de concepto de RCE funcionaban con alta fiabilidad y que ya existían prototipos públicos, lo cual siempre acelera la adopción por parte de atacantes.
Ahora, ojo con un malentendido común: como React nació para correr principalmente en el navegador, hay proyectos antiguos o configuraciones donde RSC está desactivado y, en esos casos, el riesgo puede ser menor o nulo. Pero que tú “no uses funciones del servidor” no significa automáticamente que estás a salvo: RSC podría seguir activo por configuración, dependencias o defaults.
De hecho, sitios creados con versiones recientes y setups por defecto (por ejemplo, un proyecto de Next.js levantado con create-next-app) son los que más suelen quedar dentro del radio de exposición si no se aplican parches y mitigaciones.
El grupo de monitoreo de internet Shadowserver reportó que identificó 77,664 direcciones IP expuestas y potencialmente vulnerables a la falla React2Shell, y que cerca de 23,700 de ellas estarían ubicadas en Estados Unidos.
Distribución geográfica de direcciones IP vulnerables (Fuente: ShadowServer)
¿Y cómo llegaron a ese número? Según los investigadores, usaron una técnica de detección desarrollada por Searchlight Cyber / Assetnote: básicamente, envían una solicitud HTTP diseñada para “probar” el comportamiento del servidor y luego validan una respuesta específica que confirma si el objetivo podría ser vulnerable.
Por su parte, GreyNoise observó 181 IPs únicas intentando explotar la vulnerabilidad. La mayoría del tráfico parecía automatizado (típico de bots que escanean internet a gran escala), y los intentos se concentraron principalmente en Países Bajos, China, Estados Unidos, Hong Kong y algunos otros países.
Direcciones IP únicas observadas al escanear React2Shell (Fuente: Greynoise)
El punto más serio lo puso Palo Alto Networks, que afirmó que más de 30 organizaciones ya habrían sido comprometidas por React2Shell. De acuerdo con su análisis, los atacantes estarían usando la falla para ejecutar comandos, hacer reconocimiento del entorno y tratar de robar archivos de configuración y credenciales de AWS. Incluso se mencionan intrusiones relacionadas con actores de amenazas chinos asociados a operaciones con respaldo estatal.
Podría interesarte leer: Botnet Aisuru: Cómo logró el Ataque DDoS Récord de 29,7 Tbps
Si usas React, la recomendación es subir a 19.0.1, 19.1.2 o 19.2.1.
Si usas Next.js, lo ideal es actualizar a 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 o 16.0.7.
La lógica es simple: sin parche, cualquier otra medida es solo un “parche temporal”.
Varios proveedores ya publicaron reglas para bloquear intentos de explotación a nivel de WAF:
Akamai: reglas para usuarios de App & API Protector.
AWS: las reglas están en el set estándar de AWS WAF, pero debes activarlas manualmente.
Cloudflare: protege a todos los clientes, incluso plan gratuito, siempre que tu tráfico pase por Cloudflare WAF. En planes Pro/Business/Enterprise, conviene validar que la regla esté activa.
Google Cloud: reglas de Cloud Armor para Firebase Hosting y Firebase App Hosting se aplican automáticamente.
Vercel: reglas aplicadas automáticamente.
Eso sí: todos los proveedores lo dejan claro (y con razón): el WAF no reemplaza el parcheo, solo te compra tiempo mientras actualizas. Los componentes RSC deben quedar actualizados en todos tus proyectos.
La alternativa menos invasiva es implementar reglas de detección en tu WAF o firewall para frenar patrones asociados a la explotación.
Si tu entorno no soporta inspección granular, identifica servidores con RSC activo (endpoints de funciones del servidor) y limita el acceso al máximo:
En servicios internos: bloquea todo lo que no venga de rangos IP confiables.
En servicios públicos: sube el nivel de filtrado por reputación de IP y aplica rate limiting agresivo para frenar scans automatizados.
Un agente EPP/EDR en los servidores con RSC te da una capa extra: ayuda a detectar comportamientos raros después de un intento de explotación (procesos inesperados, ejecución de comandos, accesos anómalos) y puede frenar el avance del atacante antes de que escale.
Para sumar defensa en profundidad, en TecnetOne podemos complementar esta capa con nuestro SOC as a Service, centralizando la visibilidad de endpoints, servidores y nube para detectar y responder más rápido. Además, con análisis de vulnerabilidades y pentesting se puede confirmar si existen servicios expuestos, priorizar el parcheo y verificar que las medidas de mitigación quedaron aplicadas correctamente.
Conoce más sobre: Contratar Pentesting: Checklist para Contratar sin Sorpresas
React2Shell (CVE-2025-55182) es el tipo de vulnerabilidad que no deja espacio para “luego lo vemos”: si tienes React/Next.js con RSC en producción y estás expuesto a internet, el riesgo es real y el impacto puede ser serio. La prioridad es clara: actualizar a versiones corregidas, redeplegar y verificar que no quedó ningún componente vulnerable en tu cadena de dependencias.
A partir de ahí, suma defensa en profundidad: WAF para ganar tiempo, reducción de superficie de ataque, monitoreo y EPP/EDR para detectar comportamientos anómalos. Y si necesitas apoyo, en TecnetOne podemos ayudarte con nuestro SOC 24/7 para mejorar visibilidad y respuesta, además de servicio de pentesting para confirmar exposición, validar parches y reducir el riesgo de reincidencia.