El mundo de la ciberseguridad está revolucionado por React2Shell (CVE-2025-55182), una vulnerabilidad crítica de ejecución remota de código (RCE) que afecta a React y Next.js. La magnitud de la amenaza es enorme: los investigadores ya han identificado más de 77.000 direcciones IP vulnerables expuestas a internet y han confirmado que actores patrocinados por estados y mineros de criptomonedas oportunistas ya han vulnerado al menos 30 organizaciones.
Pero si se analiza con atención, esto no es realmente una historia sobre React.
Es una historia sobre el robo de identidad de infraestructura.
Cuando un atacante explota React2Shell, no solo irrumpe en su red; se convierte en su aplicación. Hereda la identidad, las claves de API y la confianza implícita que su backend deposita en sus servidores frontend. Esto transforma un fallo de código en una crisis de identidad para sus API internas, rompiendo la barrera de confianza entre su frontend y sus datos críticos.
El "giro": de la RCE en el frontend a la brecha de la API
React2Shell explota un fallo en el protocolo "Flight" utilizado por los React Server Components para serializar datos. Al enviar una carga útil maliciosa, a menudo disfrazada dentro de una solicitud HTTP estándar mediante la cabecera next-action, un atacante no autenticado puede engañar al servidor para que ejecute código arbitrario.
Aquí es donde la historia cambia. Una vez que un atacante logra ejecutar código en su servidor Next.js, no se detiene ahí. Básicamente, toma el control de un nodo de confianza dentro de su red.
Según análisis exhaustivos realizados por investigadores de seguridad, los atacantes ya están utilizando este punto de apoyo para extraer credenciales en la nube, acceder a servicios de metadatos e implementar puertas traseras como Sliver. Para sus sistemas backend, las solicitudes que provienen de este servidor comprometido parecen legítimas. Esto crea una plataforma de lanzamiento perfecta para el movimiento lateral dentro de la red.
El impacto real: 7 formas en las que React2Shell compromete sus API
Una vez establecida esta cabeza de playa, el atacante puede utilizar el servidor comprometido para atacar su ecosistema de API internas. Esto abre la puerta a siete riesgos distintos:
- Acceso a API ocultas (Shadow APIs): Los atacantes pueden buscar y acceder a API de microservicios internos que nunca debieron exponerse a internet, eludiendo la oscuridad que normalmente las protege.
- Omisión de controles de acceso: Debido a que la solicitud proviene de una IP interna de confianza (el servidor web), a menudo elude las estrictas comprobaciones de autenticación, las reglas de WAF o las listas de permitidos de IP destinadas al tráfico externo.
- Robo de identidad en la nube: Los atacantes se dirigen específicamente a las API de metadatos de la nube (por ejemplo, 169.254.169.254) para robar credenciales IAM temporales, lo que les permite escalar privilegios dentro de su entorno en la nube.
- Robo de datos confidenciales: Los atacantes pueden consultar directamente las bases de datos del backend o los almacenes de datos de los usuarios, exfiltrando grandes cantidades de información de identificación personal (PII) sin activar las alarmas perimetrales.
- Modificación de la lógica del backend: Con acceso a las API de configuración interna, los atacantes podrían alterar potencialmente la lógica empresarial o concederse acceso administrativo persistente.
- Secuestro de recursos: Los atacantes pueden abusar de sus recursos de API internos para implementar mineros de criptomonedas o lanzar ataques de denegación de servicio (DoS) contra otros servicios internos.
- Compromiso total del entorno (movimiento lateral): Desde el servidor web, pueden moverse lateralmente hacia otros contenedores, canalizaciones de CI/CD o componentes de infraestructura confidenciales.
Por qué la defensa perimetral no es suficiente
Las herramientas de seguridad tradicionales, como los WAF, tienen dificultades para detectar esto.
- El exploit inicial: La carga útil maliciosa de React2Shell a menudo elude los WAF porque aparece como datos de aplicación serializados válidos (utilizando el encabezado next-action).
- El tráfico interno: Una vez que el atacante está dentro, su tráfico es Este-Oeste (de servidor interno a servidor interno). La mayoría de las herramientas de seguridad perimetral no detectan esto. Protegen la puerta principal, pero no tienen visibilidad de lo que sucede en el pasillo.
Cómo Salt Security cierra la brecha
React2Shell valida exactamente por qué la visibilidad de la API Este-Oeste es fundamental. No puede depender únicamente del perímetro.
Salt Security le protege de dos formas clave:
1. Descubrimiento de la superficie de ataque de la API
No puede proteger su backend si no sabe lo que expone. Salt descubre automáticamente toda su huella de API, identificando las API en la sombra y los endpoints internos a los que apuntaría un frontend comprometido. Al mapear todo su ecosistema de API, Salt le ayuda a comprender el posible "radio de explosión" de una brecha en el frontend como React2Shell, asegurando que sepa exactamente qué datos y servicios críticos son accesibles desde su capa web.
2. Monitoreo del "usuario interno de confianza" (tráfico Este-Oeste)
El aspecto más peligroso de React2Shell es que el ataque proviene de una fuente confiable: su propio servidor web. Para su red interna, estas solicitudes parecen legítimas porque se originan desde una dirección IP válida y autorizada.
Salt Security adopta un enfoque diferente. No solo observamos el origen del tráfico; analizamos el comportamiento de la identidad.
- Establecimiento de una base de confianza: Salt establece una línea base del comportamiento normal para cada activo. Sabemos que su frontend de Next.js suele llamar a APIs de consumo específicas para obtener el contenido de las páginas.
- Detección de abusos tras la explotación: Si ese servidor de confianza comienza repentinamente a escanear puertos internos, a llamar a APIs administrativas que nunca antes había utilizado o a consultar servicios de metadatos en la nube (una señal clara de la cadena de ataque de React2Shell), Salt identifica inmediatamente esta desviación. Detectamos las consecuencias de la brecha y el movimiento lateral, incluso si el exploit inicial logró eludir el WAF.
Conclusión
React2Shell es un recordatorio importante de que su modelo de seguridad no puede asumir que el frontend es seguro. Un solo fallo en un framework web puede volver su propia infraestructura de confianza en su contra.
Para proteger sus datos, debe mirar más allá del perímetro y observar lo que sucede detrás del servidor web. Parchear esta CVE específica es necesario, pero la verdadera resiliencia requiere una estrategia que asuma que la brecha ya ha ocurrido. Necesita la visibilidad profunda e interna de las APIs que solo Salt Security proporciona para garantizar que, cuando ocurra el próximo día cero en el frontend, sus datos de backend permanezcan fuera de alcance.
Si desea obtener más información sobre Salt y cómo podemos ayudarle, por favor contáctenos, programe una demostración, o visite nuestro sitio web. También puede obtener una evaluación gratuita de la superficie de ataque de sus APIs por parte del equipo de investigación de Salt Security y descubrir lo que los atacantes ya saben.