Un paquete malicioso publicado en el marketplace de Cursor el 29 de octubre replicó la identidad de Anthropic para inyectar acceso remoto persistente en estaciones de trabajo de desarrolladores.
El 29 de octubre de 2026, una extensión falsificada que se presentaba como Claude Code (anthropic.claude-code, versiones 2.1.313 y 2.1.312) estuvo disponible en el marketplace de Cursor durante aproximadamente 11 horas — desde las 2:27 AM hasta la 1:35 PM hora del Pacífico — antes de ser retirada. El paquete malicioso no llegó al Visual Studio Marketplace de Microsoft ni al registro npm, y Anthropic confirmó a Microsoft que sus sistemas no fueron comprometidos y que no desarrollaron el código en cuestión. Toda la evidencia disponible indica que el incidente se limitó al marketplace de Cursor, pero cualquier usuario que haya instalado o actualizado automáticamente la extensión durante esa ventana temporal quedó expuesto a un backdoor SSH con capacidad de persistencia.
Cómo funciona el loader inyectado en el código legítimo de la extensión
El código malicioso se ejecuta antes de la inicialización normal de la extensión, aprovechando las APIs de Node.js para recopilar información del host, modificar archivos del sistema y ejecutar comandos del sistema operativo. La función inyectada opera en silencio: suprime la salida de comandos y captura errores sin mostrarlos, permitiendo que la extensión continúe funcionando con normalidad para no alertar al usuario. Esto significa que un desarrollador podría haber usado la extensión durante horas sin notar ningún comportamiento anómalo mientras el loader completaba su secuencia de acciones en segundo plano.
La primera etapa del ataque recopila hostname, nombre de usuario, sistema operativo, arquitectura, directorio home, directorio de trabajo y el email global configurado en Git. Además, el loader busca nombres de variables de entorno que contengan términos como KEY, TOKEN, SECRET, PASS, AWS o GCP, conservando hasta cuarenta coincidencias. Es importante aclarar que el código captura los *nombres* de esas variables, no sus valores — lo que revela categorías de configuración sensible presentes en el sistema pero no demuestra robo directo de credenciales en esta etapa. Esa información queda retenida para ser enviada en un callback retrasado que se ejecuta después de completar la configuración de acceso y persistencia.
Dos identidades SSH con roles distintos: autorización local y túnel saliente
El ataque utiliza dos claves SSH separadas. Primero, el loader verifica si el archivo authorized_keys del usuario contiene el comentario «svc-telemetry». Si no lo encuentra, agrega una clave pública Ed25519 embebida en el código malicioso. Esa entrada autoriza el acceso SSH a la cuenta del usuario desde cualquier sistema que posea la clave privada correspondiente, sujeto a la configuración del servidor SSH local. La clave queda instalada de forma permanente a menos que el usuario la elimine manualmente.
La segunda identidad es una clave privada que el loader decodifica y escribe en un archivo temporal oculto (con nombre que comienza con .stk_ seguido de diez caracteres hexadecimales derivados del hostname y el directorio home). Esa clave se usa para autenticar una conexión SSH saliente hacia un servidor controlado por los atacantes, utilizando la cuenta remota «tunnel». El comando ejecutado incluye los argumentos -N -R ‘*:0:localhost:22’, que configuran un túnel SSH inverso: el servidor del atacante puede reenviar tráfico hacia el puerto 22 (SSH) de la estación de trabajo comprometida, estableciendo acceso remoto incluso si la máquina está detrás de un firewall o NAT. Esta técnica corresponde a Protocol Tunneling (T1572) en el marco MITRE ATT&CK.
Persistencia específica por plataforma y reporte retrasado de reconocimiento
Después de intentar habilitar el servicio SSH local y establecer el túnel inverso, el loader configura mecanismos de persistencia adaptados al sistema operativo. En Linux y macOS, escribe scripts y configuraciones de inicio que relanzan la conexión automáticamente al reiniciar el sistema o al iniciar sesión. En Windows, el código intenta configurar tareas programadas o entradas de registro equivalentes. Todos estos artefactos se escriben de forma silenciosa, sin solicitar permisos adicionales ni mostrar notificaciones al usuario.
Finalmente, un callback retrasado intenta transmitir los detalles del host recopilados en la primera etapa (hostname, usuario, arquitectura, nombres de variables de entorno sensibles) hacia un servidor remoto. El análisis de Microsoft no especifica el protocolo ni la dirección de destino de esa transmisión, pero confirma que el código está diseñado para enviar esa información después de completar la configuración de acceso. El éxito de cada etapa depende de los privilegios del usuario, la configuración del SSH local y la disponibilidad del servidor del atacante — pero incluso si el túnel falla, el loader puede dejar instaladas las claves SSH y los artefactos de persistencia, que quedan activos para intentos posteriores.
Por qué América Latina queda expuesta por la dependencia de herramientas de desarrollo centralizadas
Aunque Microsoft no reporta datos de descarga por región, el incidente afecta a cualquier desarrollador que use Cursor con actualizaciones automáticas habilitadas, independientemente de su ubicación geográfica. En América Latina, donde equipos de desarrollo en Argentina, Brasil, México, Chile y Colombia han adoptado herramientas de IA asistida para código en los últimos dos años, la dependencia de marketplaces centralizados como el de Cursor introduce un punto de falla único: un paquete malicioso publicado durante 11 horas puede comprometer estaciones de trabajo en decenas de empresas de la región sin que ninguna de ellas haya cometido un error de configuración local.
El riesgo se amplifica en contextos donde los desarrolladores trabajan con acceso a infraestructura cloud de producción desde sus máquinas locales — una práctica común en startups y equipos remotos de la región. Si un atacante logra acceso SSH persistente a una estación de trabajo con credenciales de AWS, GCP o Azure configuradas en variables de entorno (exactamente el tipo de información que el loader buscaba), el impacto puede escalar de un endpoint comprometido a un movimiento lateral hacia servicios cloud corporativos. La ventana de 11 horas coincidió con horarios laborales en la costa oeste de Estados Unidos, pero también con la tarde y noche en zonas horarias de América Latina, aumentando la probabilidad de que desarrolladores activos hayan ejecutado actualizaciones automáticas durante ese período.
Nuestro análisis
Este incidente confirma un patrón que ya vimos en ataques previos a registros de paquetes como npm, PyPI y RubyGems: los atacantes no necesitan comprometer la infraestructura del proveedor legítimo (en este caso, Anthropic) para distribuir código malicioso bajo su identidad. Basta con publicar un paquete con nombre y metadatos convincentes en un marketplace que no valide la autenticidad del publicador. Cursor retiró la extensión en menos de 12 horas, pero esa ventana temporal es suficiente para que sistemas con actualizaciones automáticas descarguen e instalen el código sin intervención del usuario.
Lo que distingue este caso de otros ataques de typosquatting es la sofisticación del payload: en lugar de descargar un ejecutable adicional o exfiltrar datos de inmediato, el loader usa herramientas nativas del sistema (SSH, scripts de inicio, APIs de Node.js) para establecer acceso persistente que sobrevive reinicios y puede pasar desapercibido durante semanas. El uso de túneles SSH inversos permite evadir firewalls corporativos, y la supresión de errores garantiza que la extensión siga funcionando normalmente incluso si alguna etapa del ataque falla. Todavía no sabemos cuántos sistemas fueron comprometidos, si el servidor del atacante sigue operativo, ni si se produjo exfiltración de credenciales más allá de los nombres de variables de entorno. Tampoco está claro si el atacante apuntaba a organizaciones específicas o si se trató de un ataque oportunista de amplio espectro. ¿Cuántos otros marketplaces de extensiones operan sin validación de identidad del publicador, y cuánto tiempo pasará antes de que veamos el mismo patrón replicado en otro ecosistema de desarrollo?