Icono del sitio Una Al Día

React2Shell (CVE-2025-55182) se explota para robar secretos en masa en apps Next.js

Una campaña automatizada está explotando React2Shell (CVE-2025-55182) para lograr RCE preautenticación en aplicaciones Next.js y desplegar recolección de secretos a gran escala. Tras comprometer el servidor, los atacantes exfiltran variables de entorno, tokens, claves SSH y credenciales cloud, por lo que cualquier secreto accesible desde el host debe considerarse comprometido y rotarse de inmediato.

El ecosistema de aplicaciones modernas basadas en Node.js, Next.js y React suele concentrar en el runtime una cantidad significativa de secretos operativos: desde API tokens para servicios externos hasta credenciales de bases de datos, accesos a cloud y claves usadas por automatizaciones. Esa realidad convierte a los fallos que permiten ejecutar código en el servidor en una vía especialmente rentable para atacantes: no buscan solo tumbar servicios, sino convertir el servidor en una aspiradora de credenciales con impacto inmediato en cuentas, datos y facturación.

En ese contexto, una campaña activa está abusando de React2Shell (CVE-2025-55182) para conseguir Remote Code Execution (RCE) sin autenticación contra aplicaciones Next.js vulnerables, en particular escenarios ligados a React Server Components (RSC) y Server Functions expuestas. El vector se apoya en el procesamiento de payloads enviados a endpoints del lado servidor, donde el manejo inseguro permite encadenar la ejecución de comandos dentro del proceso Node.js que atiende la aplicación. Una vez obtenido el control, el objetivo no se limita a la persistencia: el foco principal es el robo sistemático de secretos y material de acceso.

La operativa observada destaca por su automatización. En un intervalo de 24 horas se identificaron al menos 766 hosts comprometidos, repartidos entre distintas regiones y proveedores. Tras la intrusión, se ejecutan scripts lanzados con nohup, habitualmente desde /tmp y con nombres aleatorios u ocultos, para mantener la recolección en segundo plano y por fases. Esa ejecución por etapas facilita que el atacante vaya ampliando el inventario de credenciales: primero obtiene información básica del sistema y variables relevantes, después profundiza en llaves, tokens y configuraciones, y finalmente empaqueta y envía los hallazgos.

La extracción incluye variables de entorno y secretos de runtime donde suelen vivir credenciales de PostgreSQL/MySQL, claves de servicios externos y tokens de desarrollo como GitHub o GitLab. También se buscan y copian claves privadas SSH (formatos ED25519 y RSA) y ficheros como authorized_keys, lo que abre la puerta a movimiento lateral hacia otros servidores si existe reutilización de claves o confianza implícita entre máquinas. En entornos con contenedores, se intenta enumerar configuraciones de Docker y, cuando hay orquestación, se prueban rutas habituales para obtener Kubernetes service account tokens, con el riesgo de escalar desde un pod a recursos del clúster si los permisos están sobredimensionados.

Una parte especialmente crítica es el robo de credenciales cloud mediante consultas a APIs de metadatos en AWS, GCP y Azure. En el caso de AWS, el abuso de Instance Metadata Service (IMDS) puede proporcionar credenciales temporales asociadas a IAM roles, suficientes para listar recursos, extraer datos o incluso modificar infraestructura si el rol no sigue el principio de mínimo privilegio. En paralelo, se han visto intentos de localizar secretos de terceros de alto impacto económico, como claves en vivo de Stripe (patrones sk_live_), además de credenciales para plataformas de correo y mensajería como SendGrid o bots de Telegram, y tokens de servicios de IA como OpenAI o Anthropic*, que pueden derivar en fraude, abuso de cuota o exposición de datos.

La exfiltración se realiza mediante peticiones HTTP hacia infraestructura de C2, con tráfico que con frecuencia aparece por el puerto 8080 y con identificadores que reflejan el host y la fase de recolección. La campaña se apoya en un framework con interfaz web denominado NEXUS Listener, asociado a un clúster rastreado como UAT-10608, diseñado para gestionar en volumen la captura de secretos y su clasificación.

La implicación práctica es clara: si una app expuesta era vulnerable, no basta con parchear. Cualquier token, API key, credencial de base de datos, clave SSH o secreto accesible desde el proceso comprometido debe tratarse como filtrado. La respuesta debe combinar actualización o mitigación de CVE-2025-55182, rotación inmediata de credenciales, revisión de authorized_keys, endurecimiento de metadatos (por ejemplo, forzar IMDSv2 en EC2), auditoría de permisos IAM y RBAC en Kubernetes, y vigilancia de indicadores como ejecuciones anómalas desde /tmp, procesos persistentes con nohup y conexiones salientes inusuales hacia destinos externos.

Más información

Acerca de Hispasec

Hispasec Ha escrito 65 publicaciones.

Salir de la versión móvil