React2Shell explota Next.js para un saqueo masivo de credenciales que compromete 766 hosts en 24 horas

Una operación automatizada de gran alcance está aprovechando una vulnerabilidad en aplicaciones Next.js para arrancar un robo masivo de credenciales que, según los investigadores, ya ha comprometido cientos de servidores en la nube. El vector explotado es conocido como React2Shell (CVE-2025-55182) y, una vez que el atacante obtiene acceso, despliega scripts que muestrean y exfiltran secretos, claves y credenciales de forma sistemática.

Los detalles técnicos y el seguimiento de la campaña han sido documentados por los analistas de Cisco Talos, que atribuyen la operación a un clúster de amenazas identificado como UAT-10608. En su investigación los expertos pudieron acceder a una instancia expuesta del componente de control llamado NEXUS Listener, lo que les permitió observar en directo la información que los intrusos estaban recopilando y cómo la presentaban: una interfaz que agrupa y facilita la búsqueda, el filtrado y la estadística de los secretos sustraídos. Puede consultarse el informe de Talos para ampliar los hallazgos y ver capturas del panel: Cisco Talos — Inside a large-scale automated credential-harvesting operation.

El modus operandi descrito por los investigadores arranca con exploraciones automatizadas en busca de instancias Next.js vulnerables. Tras explotar React2Shell, el atacante deja caer un script en un directorio temporal que ejecuta una rutina en varias fases para extraer secretos y ficheros sensibles. Ese material se empaqueta en fragmentos y se envía por HTTP al servidor de mando y control —el NEXUS Listener— tipicamente a través del puerto 8080, donde queda indexado y disponible para su análisis por los operadores maliciosos.

La magnitud del incidente es llamativa: Talos informó que la infraestructura de explotación fue capaz de comprometer al menos 766 hosts en un periodo de 24 horas. Entre los elementos que los atacantes recolectaron se cuentan variables de entorno y secretos de aplicaciones (API keys, credenciales de bases de datos, tokens de GitHub/GitLab), claves SSH privadas, credenciales de nube (metadatos y credenciales IAM de AWS/GCP/Azure), tokens de Kubernetes, información de contenedores y Docker, historiales de comandos y datos de procesos en ejecución.

El riesgo no se limita a la pérdida puntual de secretos. Con estos elementos un atacante puede realizar toma de control de cuentas cloud, acceder a bases de datos y sistemas de pago, moverse lateralmente usando claves SSH o lanzar ataques a la cadena de suministro aprovechando accesos persistentes. También existe un coste regulatorio porque la exfiltración puede incluir datos personales sujetos a normativas de privacidad.

Ante este tipo de campañas, las recomendaciones de los equipos de respuesta combinan medidas inmediatas y estratégicas. En lo urgente, es imprescindible aplicar los parches que cierren React2Shell y, ante la mínima sospecha de exposición, rotar todas las credenciales afectadas. Cisco Talos insiste en la necesidad de auditar posibles exposiciones de datos en el servidor y sustituir claves SSH reutilizadas. Para la defensa a nivel cloud, es recomendable forzar el uso de IMDSv2 en instancias EC2 de AWS para dificultar la obtención de metadatos de instancia por parte de procesos comprometidos; la documentación oficial de AWS explica cómo configurar y forzar IMDSv2: AWS — Configuring the Instance Metadata Service.

Otras medidas preventivas incluyen la adopción de escaneo de secretos en repositorios y pipelines (por ejemplo, las soluciones de secret scanning que ofrecen plataformas como GitHub), la rotación periódica y automatizada de credenciales, la aplicación estricta del principio de menor privilegio en roles y permisos de contenedores y cuentas cloud, y la implementación de protecciones de aplicación como WAF o RASP para reducir la probabilidad de explotación de fallos en aplicaciones web. GitHub documenta sus capacidades de detección de secretos en el código y en la historia del repositorio: GitHub — Secret scanning, y la guía de OWASP sobre gestión de secretos ofrece buenas prácticas sobre almacenamiento y rotación: OWASP — Secrets Management Cheat Sheet.

En el plano operativo conviene también endurecer la detección y la telemetría: monitorizar conexiones HTTP salientes hacia puertos no habituales (como 8080) desde servidores de aplicaciones, revisar procesos y archivos en /tmp en busca de scripts maliciosos, auditar historiales de comandos y ficheros de configuración de contenedores, y establecer alertas de uso anómalo de claves y tokens. Limitar el tráfico de salida a destinos conocidos y forzar el egress filtering reduce la capacidad de un intruso de exfiltrar datos hacia infraestructuras C2.

Esta campaña vuelve a poner sobre la mesa dos ideas sencillas pero críticas: primero, que las vulnerabilidades en la capa de aplicación siguen siendo una puerta de entrada extremadamente lucrativa para los atacantes; y segundo, que la protección de secretos y credenciales debe ser tanto preventiva como reactiva. Aplicar parches con rapidez, auditar la exposición de información sensible y contar con procesos automáticos para rotar y detectar secretos filtrados son pasos mínimos que hoy pueden marcar la diferencia entre un incidente contenido y una brecha con consecuencias de largo alcance.

Para leer el análisis técnico y los indicadores compartidos por los investigadores, consulte el informe de Cisco Talos: Inside a large-scale automated credential-harvesting operation. Si necesita orientación práctica para auditar su entorno o priorizar mitigaciones, las guías de AWS y OWASP enlazadas arriba son buenos puntos de partida.