El 29 de octubre de 2026, un evento inusual y alarmante sacudió a la comunidad de desarrolladores: una versión maliciosa de la extensión oficial de Claude Code, publicada en el marketplace de extensiones de Cursor (la empresa detrás del editor de código más popular del momento), estuvo disponible para instalación durante aproximadamente once horas, infectando hasta 5.000 usuarios. El ataque no explotaba una vulnerabilidad en el código del Claude Code — la extensión original fue simplemente reemplazada por una versión trojanizada que, al instalarse, plantaba una clave SSH controlada por el atacante en el archivo authorized_keys, intentaba habilitar el servicio SSH local y abría un túnel reverso hacia un servidor remoto.
Lo que hace que este incidente sea particularmente significativo va más allá de la sofisticación técnica del ataque. Ilustra un cambio estructural en el panorama de amenazas cibernéticas: los desarrolladores que usan herramientas de IA para programar se están convirtiendo en blancos directos de ataques de cadena de suministro, y un solo plugin malicioso puede entregar acceso root a todo el entorno de desarrollo. La extensión maliciosa, en las versiones 2.1.312 y 2.1.313, ejecutaba código malicioso antes incluso de que se llamara al callback de activación de la extensión — el código inyectado se insertaba en la carga del módulo extension.js, ejecutándose automáticamente siempre que el IDE o Cursor iniciaban.
El ataque en detalles
La extensión trojanizada contenía un loader de 66 líneas que fue prependado al bundle original de la extensión. Cuando la extensión se cargaba, el loader ejecutaba inmediatamente, sin ninguna interacción del usuario, y ejecutaba una cadena de acciones en cuatro etapas.
La primera etapa preparaba el acceso SSH. El malware aseguraba que el directorio ~/.ssh existiera y añadía una clave pública Ed25519 con el comentario `svc-telemetry` al archivo authorized_keys del usuario. Simultáneamente, intentaba habilitar el servicio SSH local — en macOS, a través del comando `systemsetup -setremotelogin on`; en Linux, vía systemctl; en Windows, activando el servidor SSH de OpenSSH. Luego, iniciaba un túnel SSH reverso continuo hacia el IP 134.209.82.225 en el puerto 8099, usando un loop de retry cada 60 segundos con `autossh`, cayendo a `ssh` si el autossh fallaba. La conexión usaba `-N -R '*:0:localhost:22'` con verificación de host deshabilitada (`StrictHostKeyChecking=no`).
La segunda etapa era la persistencia. El malware instalaba mecanismos de boot en cada plataforma: en macOS, un LaunchAgent malicioso llamado `com.apple.sysmond.plist` — nombrado intencionalmente para parecerse a un servicio legítimo de Apple — almacenado en ~/Library/LaunchAgents/; en Linux, una entrada de crontab del usuario `@reboot` ejecutando ~/.config/.smt; en Windows, una tarea programada llamada SysMon accesible via `schtasks`, con un fallback para un script en el Startup folder. El loader también escribía una clave privada en formato PEM en un archivo oculto ~/.config/.smtk y en un archivo temporal siguiendo el patrón $TMPDIR/.stk_*, creando las credenciales que sustentaban tanto el túnel como la clave SSH plantada.
La tercera etapa era el beacon. El malware enviaba datos del host al servidor atacante vía HTTP puro (sin TLS) en el path /beacon — una decisión interesante que facilita la detección en el tráfico de red. Los datos incluían hostname, username, sistema operativo, arquitectura, camino del directorio home, directorio de trabajo actual, email configurado en Git, dirección IP pública y, notablemente, los nombres de variables de ambiente que coincidían con patrones como KEY, TOKEN, SECRET, PASS, AWS o GCP. El beacon enviaba hasta 40 nombres de variables por POST, pero no los valores — lo que no significa que los valores estuvieran a salvo, sino que el atacante estaba primero mapeando qué credenciales estaban disponibles en el ambiente antes de intentar acceder a ellas vía backdoor.
La cuarta etapa era la exfiltración de contexto adicional. El malware recopilaba nombres de directorios de trabajo, permitiendo que el operador entendiera qué repositorios el desarrollador estaba manipulando — información valiosa para dirigir ataques adicionales contra infraestructura de CI/CD o repositorios de código.
Por qué el ataque fue menos dañino de lo que podría haber sido
Un punto crucial: errores de codificación en el malware impidieron que funcionara como pretendido en la mayoría de las plataformas. En macOS, el comando `systemsetup -getremotelogin` retorna el código 0 con un mensaje de error cuando el Remote Login está deshabilitado — el malware interpretó ese código como éxito y dejó de intentar habilitar el SSH. Esto significa que, en la mayoría de los Macs, el túnel reverso nunca fue establecido porque el servicio SSH local no estaba corriendo y el malware no pudo activarlo.
Incluso en sistemas donde el túnel fue establecido, la conexión requería que el servidor remoto aceptara la conexión entrante y que las configuraciones del servidor permitieran login vía clave SSH — lo cual es inusual en entornos corporativos. En otras palabras, el malware plantó la clave SSH e instaló persistencia, pero raramente consiguió efectivamente abrir una puerta de entrada interactiva.
Los investigadores de Daylight Security, que monitorearon casos reales de infección entre desarrolladores, confirmaron que al menos dos casos reales fueron identificados: en ambos, herramientas EDR dispararon alertas (CrowdStrike registró eventos PemFileWritten cuando claves privadas fueron escritas en ~/.config/.smtk, y el proceso del IDE corrió comandos de SSH con `-R '*:0:localhost:22'`). Sin embargo, la extensión original Claude Code no tenía ninguna de las permisiones que el malware necesitaba — y el ataque dependió enteramente de vulnerabilidades de confianza entre el IDE y sus extensiones, no de una falla en el software en sí.
El papel de Cursor y la respuesta
Cursor actuó rápido. Una vez que el marketplace detectó la extensión maliciosa, fue removida, el marketplace fue apagado completamente por precaución, las claves fueron rotadas y el marketplace fue reconstruido antes de volver al aire. Cursor confirmó que ninguna otra extensión fue comprometida y trabajó con el proveedor de hospedaje para derribar el servidor del atacante.
La empresa también emitió una guía de seguridad hardening, recomendando que organizaciones restrinjan extensiones a publicadores aprobados y configuren un cooldown de instalación — retrasando la instalación de nuevas versiones de extensiones por un período configurable. Estas medidas, sin embargo, protegen solo organizaciones corporativas que adoptan explícitamente estas configuraciones. Desarrolladores individuales que actualizan extensiones automáticamente siguen vulnerables.
Cursor estima que hasta 5.000 usuarios fueron afectados. La empresa publicó scripts de remediación específicos para cada plataforma, incluyendo instrucciones para remover el LaunchAgent malicioso, la entrada de crontab, la tarea programada en Windows y la clave SSH plantada. El punto crucial que Cursor enfatizó: desinstalar la extensión no elimina los artefactos maliciosos — el atacante diseñó el malware para sobrevivir a la remoción de la extensión, escribiendo artefactos fuera del directorio de instalación.
Qué significa esto para el futuro de la seguridad de desarrolladores
Este incidente marca un momento de inflexión. Históricamente, ataques de cadena de suministro apuntaban a bibliotecas npm, paquetes PyPI, repositorios Git o herramientas de CI/CD — blancos que exigían que el atacante comprometiera paquetes ampliamente distribuidos. La extensión Claude Code, sin embargo, era un blanco mucho más específico: una extensión de IDE usada por desarrolladores que ya estaban configurados con permisos elevados en sus propias computadoras.
Desarrolladores cargan credenciales de alto valor en sus máquinas personales: claves SSH, credenciales AWS y GCP, tokens de API, sesiones autenticadas de CI/CD. Una extensión maliciosa de IDE tiene acceso directo a todo esto — no solo porque corre en el contexto del usuario, sino porque puede leer archivos que otras herramientas maliciosas jamás alcanzarían. El malware de la extensión Claude Code no necesitó un exploit — simplemente corrió como el IDE, con las mismas permisiones.
La extensión Claude Code es un caso emblemático, pero el patrón es más amplio. A medida que desarrolladores adoptan herramientas de IA para programar — Claude Code, GitHub Copilot, Cursor, Windsurf —, cada una de estas herramientas ofrece extensiones que corren con las permisiones del IDE y del usuario. Un solo plugin malicioso puede entregar acceso root a todo el entorno de desarrollo.
Lo que diferencia este ataque de otros es el nivel de planificación. El malware fue diseñado para persistir incluso después de la desinstalación de la extensión — lo que indica que el atacante no buscaba una instalación rápida de baja complejidad, sino acceso interactivo persistente y de largo plazo. El beacon que enviaba nombres de variables de ambiente al servidor atacante sugiere que la intención era usar esas variables como contexto para ataques adicionales, quizás para rotar cuentas cloud o acceder a repositorios.
El vector de compromiso — el marketplace de extensiones de Cursor — también es interesante. Cursor no usa el Visual Studio Marketplace ni el npm para distribución; su propio marketplace es el canal de distribución. Esto significa que el atacante no necesitaba comprometer el sistema de distribución oficial de Anthropic (que, según la empresa, no fue afectado), sino aprovechar el pipeline de revisión de extensiones de Cursor — o un miembro del equipo con acceso privilegiado — para publicar una versión trojanizada de la extensión oficial.
La pregunta en el aire es si las extensiones de IDE alimentadas por IA pueden alguna vez ser completamente confiables sin cambios fundamentales en cómo los marketplaces de extensiones operan. Hasta que haya un requisito de firma criptográfica para extensiones, aislamiento de runtime para código de extensiones, o procesos de revisión obligatorios que vayan más allá de verificaciones automáticas simples, desarrolladores instalando extensiones en su IDE están, efectivamente, haciendo un salto de fe.
Fuentes: Cursor, Microsoft Security Research, Netskope Threat Labs
✓ Fuentes independientes cruzadas y verificadas antes de la publicación
