La vulnerabilidad 10.0 en SimpleHelp abre la puerta a un stealer que roba tokens de Claude, Gemini y Codex

Una falla crítica de bypass de autenticación en el software de acceso remoto SimpleHelp está en explotación activa desde la semana pasada y ha servido como puerta de entrada para dos artefactos inéditos: un loader escrito en Node.js llamado TaskWeaver y un infostealer multiplataforma llamado Djinn Stealer. La investigación fue publicada el lunes 30 de junio por el Adversary Pursuit Group (APG), unidad de respuesta de Blackpoint Cyber, y replicada por The Hacker News, Help Net Security y otros medios a lo largo del día.

La vulnerabilidad recibió el identificador CVE-2026-48558, con un CVSS de 10,0. Está en el flujo OpenID Connect (OIDC) de SimpleHelp: el servidor no verifica la firma criptográfica del token de identidad y, por lo tanto, acepta un token forjado con claims arbitrarios. Un invasor no autenticado puede abrir una sesión de "Technician" completamente válida. Si el técnico aún no ha configurado el segundo factor, puede registrarlo, lo que anula la protección de MFA que muchas equipos creían tener. SimpleHelp corrigió la falla a finales de mayo, en las versiones 5.5.16 y 6.0 RC2; todas las versiones anteriores siguen expuestas.

Cómo se montó la cadena de intrusión

Según el informe de Blackpoint, el operador explotó SimpleHelp en el borde de la red de la víctima, obtuvo sesión privilegiada y utilizó los propios recursos de transferencia de archivos y ejecución remota del producto para distribuir la carga en masa. El archivo entregado se presenta como jquery.js, hospedado en un endpoint efímero en Cloudflare. No es jQuery. Es TaskWeaver, un loader modular en Node.js que primero identifica el sistema, establece un canal cifrado con el servidor de comando y luego pide cargas adicionales en JavaScript, ejecutadas con privilegios elevados.

La carga parece deliberadamente diseñada para evadir el análisis estático de EDRs corporativos que confían demasiado en el dominio de Cloudflare y ignoran binarios firmados como "biblioteca web". El segundo etapa es el Djinn Stealer, que corre en Windows, macOS y Linux.

El activo que el atacante desea es el token del agente de IA

Es en este punto que el incidente sale de la rutina. El Djinn Stealer escanea archivos de configuración y sesiones de autenticación para proveedores tradicionales (AWS, Azure, Google Cloud, Oracle Cloud, Okta, Cloudflare) y también para asistentes de codificación con IA: Claude, Gemini, Codex, Cline, OpenCode y Kilo. El objetivo específico son los archivos que almacenan la configuración del Model Context Protocol (MCP), como ~/.claude/mcp.json.

Estos archivos contienen los tokens que el desarrollador entrega a su agente para acceder a repositorios, bases de datos, cuentas de nube y APIs internas. Según el texto de Blackpoint, "robarles otorga al invasor el mismo acceso downstream que el desarrollador extendió a su agente de IA, yendo mucho más allá del servicio de IA en sí". Traduciendo para el operador de SOC: el mismo par de llaves que hace que el agente abra un pull request también lo hace el intruso.

Antes de exfiltrar, el Djinn empaqueta todo en TAR, comprime con GZIP y cifra con AES-256-GCM, cuya clave está protegida por un RSA-2048 embebido en el propio TaskWeaver. Sin acceso al binario, el defensor no descifra lo que salió.

El reloj de la CISA y el efecto sobre equipos globales

La CISA incluyó la CVE-2026-48558 en el Known Exploited Vulnerabilities Catalog y obligó a agencias del ejecutivo civil federal (FCEB) a aplicar el patch hasta el 2 de julio. El plazo funciona como señal para el mercado privado: aseguradoras y equipos de riesgo suelen usar la KEV como desencadenante para exigir remediación en compromisos contractuales. Proveedores de servicios gestionados (MSPs) que ejecutan SimpleHelp para atender a clientes en diferentes regiones concentran un riesgo especial. Un único servidor expuesto del MSP en Dublín, Manila o Bangalore puede convertirse en ruta lateral para decenas de cuentas de clientes, incluyendo operaciones brasileñas de multinacionales estadounidenses y europeas que subcontratan soporte L2.

Para los equipos de seguridad que ya han adoptado asistentes de código con MCP en producción, la alerta es doble. Primero, tratar los tokens de MCP como credenciales de infraestructura, con rotación frecuente y un cofre dedicado, y no como un archivo de configuración de aplicación. Segundo, revisar qué scopes han sido otorgados al agente. Un Claude configurado con MCP para GitHub, S3 y Postgres tiene, en la práctica, tres credenciales de alto privilegio guardadas en el mismo JSON, una promesa demasiado dulce para el operador que ya ha demostrado saber dónde buscar. La ventana en la que el mercado de seguridad discutía "cómo actúa el agente" acaba de volverse más estrecha; ahora el debate es cómo impedir que sea robado antes de actuar.