ESTOY BAJO UN CIBER ATAQUE

Alerta

Logo de Cursor

Alerta 2026-132 Versión troyanizada de la extensión Claude Code en el marketplace de Cursor instala una puerta trasera SSH

Producto(s) afectado(s): 

ProductoVersiones afectadasVersión corregida
Extensión Claude Code para VS Code (anthropic.claude-code) distribuida por el marketplace de extensiones de Cursor2.1.313 (únicamente), instalada o actualizada el 29/10/2026 entre las 06:27 y las 17:35 (PYT, UTC-3)2.1.314 o posterior

Afecta a los usuarios de Cursor que instalaron o actualizaron la extensión en esa ventana, incluida la actualización automática; no hay evidencia de que otros canales de distribución ni otras extensiones del marketplace se hayan visto afectados.

Descripción

Se ha hecho pública la distribución de una versión troyanizada de la extensión oficial Claude Code para VS Code, identificada como anthropic.claude-code 2.1.313, a través del marketplace de extensiones del editor Cursor. Durante unas 11 horas del 29/10/2026, esta versión intentó instalar una puerta trasera SSH persistente en los equipos de los desarrolladores. Se trata de un compromiso de la cadena de suministro: la versión utilizó el identificador legítimo de la extensión, pero el proveedor de Cursor indicó que no fue desarrollada por Anthropic, editor de la extensión. El incidente no tiene CVE asignado y se clasifica con severidad ALTA.

El proveedor indicó que hasta 5.000 usuarios de Cursor recibieron la versión troyanizada y que se comunicará directamente con ellos. Esta cifra es un máximo de usuarios expuestos, es decir, que instalaron o actualizaron a la 2.1.313; no es un número de equipos con compromiso confirmado. El proveedor no ha publicado cuántos equipos tuvieron la clave del atacante agregada ni cuántos túneles llegaron a establecerse.

El proveedor retiró la versión, bloqueó su distribución y apagó todo el marketplace por precaución; luego auditó los accesos, confirmó que ninguna otra extensión fue alterada, rotó sus claves, reconstruyó el marketplace y lo volvió a poner en línea. Además, el servidor del atacante fue dado de baja con su proveedor de nube. No se ha divulgado cómo se introdujo el paquete en el marketplace ni se ha atribuido el ataque a ningún actor. No hay evidencia de que la versión 2.1.313 se haya distribuido por npm, por el Visual Studio Marketplace de Microsoft ni por el registro Open VSX.

Investigadores señalan que el paquete contiene un cargador de 66 líneas antepuesto al archivo extension.js legítimo. Ese código se ejecuta cuando el editor carga la extensión, sin interacción del usuario ni scripts de instalación, y suprime sus errores para que la extensión siga funcionando con normalidad. Los paquetes identificados corresponden a macOS (Apple Silicon) y Windows (x64), y el código malicioso incluye también una rama para Linux. Al ejecutarse:

  • Recopila el nombre del equipo, el usuario, el sistema operativo y la arquitectura, el directorio personal y el de trabajo, el correo de Git configurado, la IP pública y los nombres (no los valores) de hasta 40 variables de entorno que contengan KEY, TOKEN, SECRET, PASS, AWS o GCP.
  • Agrega una clave SSH del atacante, con el comentario svc-telemetry, al archivo ~/.ssh/authorized_keys e intenta habilitar el servicio SSH local.
  • Abre un túnel SSH inverso hacia 134.209.82.225 (puerto 22), que se reintenta cada 60 segundos aproximadamente, y lo hace persistente con un LaunchAgent en macOS, con una tarea programada o un script de inicio en Windows y, según el análisis de investigadores, con una entrada @reboot en el crontab en Linux.
  • Envía los datos recopilados por HTTP a 134.209.82.225:8099/beacon. No descarga una segunda etapa.

El proveedor señala que habilitar el servicio SSH requiere privilegios de administrador, que la extensión no tiene en la mayoría de los equipos macOS y Windows; en esos equipos el paso falla y el atacante no pudo iniciar sesión a través del túnel, salvo que el editor se ejecutara como administrador. Aun así, la clave del atacante, la persistencia y el envío de datos se completan. Investigadores advierten que, si el equipo ya tenía el acceso remoto SSH activo, o se activa más adelante, la puerta trasera queda operativa. Como el servidor del atacante está fuera de línea, el túnel y el envío de datos ya no funcionan. Hasta el momento no se ha confirmado públicamente ningún acceso del atacante a los equipos ni robo de datos más allá de la información de reconocimiento, aunque el proveedor advierte que no puede descartarse un acceso posterior a credenciales a través de la puerta trasera.

Mitigación

Para verificar si un equipo está afectado, se debe comprobar si la clave svc-telemetry está presente con los comandos publicados por el proveedor. En Linux, la misma comprobación de macOS es aplicable según el análisis de investigadores.

# macOS (y Linux, según el análisis de investigadores)
grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "svc-telemetry key found" || echo "No key found; machine not impacted"
# Windows (PowerShell)
$files = "$HOME\.ssh\authorized_keys", "C:\ProgramData\ssh\administrators_authorized_keys" | Where-Object { Test-Path $_ }
if ($files -and (Select-String svc-telemetry $files)) { "svc-telemetry key found" } else { "No key found; machine not impacted" }

También se puede revisar si existe la carpeta ~/.cursor/extensions/anthropic.claude-code-2.1.313-*. Desinstalar la extensión puede no bastar, porque la persistencia funciona por separado. Como recomendaciones generales, en los equipos donde se instaló la versión 2.1.313:

  • Buscar los indicadores de compromiso en la telemetría de endpoints, de red y de instalación de extensiones, incluidas las conexiones históricas a 134.209.82.225.
  • Aislar los equipos con evidencia y preservar la evidencia (registros de SSH, de procesos y de red) antes de limpiarlos.
  • Bloquear 134.209.82.225 en los puertos 22 y 8099.
  • Revisar en los registros de SSH si hubo inicios de sesión desde 127.0.0.1 o ::1 con la clave svc-telemetry. Si se confirma que el túnel llegó a conectarse, se recomienda reconstruir el equipo en lugar de limpiarlo.
  • Comprobar si el acceso remoto SSH (Remote Login en macOS) se habilitó sin autorización.
  • Si la versión 2.1.313 aparece instalada en cualquier otro editor, ejecutar igualmente las comprobaciones.

Indicadores de compromiso

Red

  • IP del atacante: 134.209.82[.]225, en TCP 22 (usuario tunnel) y en TCP 8099 (POST /beacon).
  • Intento de baliza local: 127.0.0.1:8099/beacon.
  • Las consultas a ifconfig.me y api.ipify.org no son indicadores por sí solas, porque son servicios legítimos. No hay dominios maliciosos.

SSH

  • Clave no autorizada: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDdvylCEJ/k2TpezcTfedrkHyFSK9IZ3vmP6vhY4Ss0P svc-telemetry.
  • Huella de la clave: SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk.
  • Huella de la clave del túnel: SHA256:KOAU57+ZG6u3MG4WwzPzPX2O5YEe9qdOC1Bl+6MVyDQ (comentario svc-telemetry-tun).
  • Según investigadores, los inicios de sesión entrantes a través del túnel aparecen en los registros de SSH como provenientes de 127.0.0.1 o ::1 con la clave svc-telemetry.

Archivos y persistencia

  • macOS: ~/Library/LaunchAgents/com.apple.sysmond.plist (etiqueta com.apple.sysmond; no es un componente de Apple), ~/.config/.smt, ~/.config/.smtk y $TMPDIR/.stk_<10 caracteres hex>.
  • Windows: la tarea programada SysMon (intenta ejecutarse como SYSTEM), %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd, %USERPROFILE%\.config\smt.cmd, %USERPROFILE%\.config\smtk, %TEMP%\.stk_<10 caracteres hex> y la clave del atacante en %USERPROFILE%\.ssh\authorized_keys o C:\ProgramData\ssh\administrators_authorized_keys.
  • Linux (según el análisis de investigadores): una entrada @reboot en el crontab del usuario que ejecuta ~/.config/.smt, además de ~/.config/.smt, ~/.config/.smtk y /tmp/.stk_*.
  • Carpeta de la extensión: anthropic.claude-code-2.1.313-darwin-arm64 o anthropic.claude-code-2.1.313-win32-x64, cuyo extension.js contiene 134.209.82.225 y svc-telemetry.

Procesos

  • ssh -N -R '*:0:localhost:22' o autossh -M 0, con StrictHostKeyChecking=no, UserKnownHostsFile=/dev/null, IdentitiesOnly=yes y BatchMode=yes.
  • schtasks /create /tn SysMon, systemsetup -setremotelogin on y Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0.

Hashes (SHA-256)

  • VSIX darwin-arm64: 432ccdee3801f99e52b8fe31f69ea9870118e96ea7ef9ecabed1479621b5ab62
  • VSIX win32-x64: 3de1722901165769893bef57c72594e9a54459faa23f3091b136b79966edd081
  • extension.js malicioso: ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15
  • Clave privada del túnel (.stk_*): 7e0a52885fadee05544a9e99eb18c792bec05900a5e1a66d68f8383decb0e278
  • smt.cmd (Windows, reportado por una sola fuente): 22f682d9ff55264e934d0f43fcfbb46d58be5cfb8fe1b3a7cbb38fe089c818b0

Solución

La solución consiste en eliminar la puerta trasera con los scripts de remediación publicados por el proveedor y actualizar la extensión a la versión 2.1.314 o posterior:

  • macOS: ejecutar el script remediate-macos.sh como el usuario afectado, no como root: bash remediate-macos.sh. El script quita la extensión alterada, la persistencia, los procesos del túnel y la clave del atacante; termina con un código distinto de cero si algo queda pendiente y avisa si hay un servicio escuchando en el puerto 22 local.
  • Windows: ejecutar el script remediate-windows.ps1 desde una consola PowerShell abierta como administrador, con todos los editores cerrados: powershell -ExecutionPolicy Bypass -File .\remediate-windows.ps1. El script limpia todos los perfiles del equipo.
  • Linux: no hay un script oficial. Según el análisis de investigadores, la limpieza manual consiste en quitar del crontab la entrada @reboot que ejecuta ~/.config/.smt (y revisar si se perdieron trabajos programados legítimos, porque un fallo del código malicioso puede borrarlos), terminar los procesos asociados con pkill -f '\.stk_|\.config/\.smtk|\.config/\.smt', borrar ~/.config/.smt, ~/.config/.smtk y /tmp/.stk_*, quitar la clave svc-telemetry de ~/.ssh/authorized_keys y revisar si el servicio SSH fue habilitado.
  • Desde un equipo de confianza, rotar las credenciales y sesiones accesibles desde el equipo afectado: tokens de GitHub y GitLab, de CI/CD y de registros de paquetes, claves de nube y claves SSH, priorizando las variables de entorno cuyo nombre contiene KEY, TOKEN, SECRET, PASS, AWS o GCP.

Información adicional: