Una copia manipulada de la extensión de Claude Code, publicada en el marketplace de extensiones de Cursor con el nombre de Anthropic, instaló un backdoor SSH persistente en equipos macOS y Windows que recibieron las versiones 2.1.312 o 2.1.313 el 29 de octubre de 2026. Desinstalar la extensión no lo elimina. La verificación es un solo comando, y está más abajo.
Cursor afirma que las versiones maliciosas no fueron desarrolladas por Anthropic. Ingenieros de Anthropic explicaron en Hacker News que los sistemas de la compañía no fueron vulnerados y que las copias del VS Code Marketplace oficial y de Open VSX no se vieron afectadas. Phorion, la firma de seguridad que publicó el primer análisis técnico, ya amplió su lista de versiones afectadas para coincidir con la de Cursor. Al momento de publicar esta nota, ni Cursor ni Anthropic habían informado cómo obtuvo el atacante acceso para publicar ni cuántos developers instalaron la versión maliciosa.
Es un caso de manual de supply chain attack: nadie tuvo que hacer clic en nada raro. Bastó con que el IDE actualizara una extensión conocida.
¿Estoy afectado por la extensión falsa de Claude Code en Cursor?
Estás dentro del alcance si se cumplen las tres condiciones:
- Usas Cursor y tenías instalada la extensión de Claude Code (
Anthropic.claude-code) desde el marketplace de Cursor. - Trabajas en macOS (Apple Silicon, darwin-arm64) o Windows (win32-x64). Son los dos builds que lista Cursor.
- La extensión se actualizó a 2.1.312 o 2.1.313 durante la ventana que indica Cursor: aproximadamente entre las 2:27 y las 13:35 (hora del Pacífico) del 29 de octubre de 2026.
Si instalaste Claude Code desde el VS Code Marketplace oficial o desde Open VSX, el registro abierto de extensiones que usan muchos editores derivados de VS Code, Anthropic dice que no estás afectado. Si nunca usas la extensión dentro de Cursor, este incidente no te aplica.
Phorion indica que las carpetas de la extensión que debes buscar son anthropic.claude-code-2.1.312-darwin-arm64 y anthropic.claude-code-2.1.313-darwin-arm64, dentro del directorio de extensiones de tu IDE. Si existe una carpeta con cualquiera de esos nombres, la versión maliciosa estuvo instalada en algún momento.
¿Cómo saber si tengo el backdoor en mi equipo?
Busca la llave SSH del atacante. El payload agrega una llave pública con el comentario svc-telemetry a tu archivo authorized_keys. Esta es la verificación de una línea que publica Cursor:
macOS:
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" }
“No key found” es la respuesta que quieres ver. Si aparece la llave, sigue leyendo.
¿Qué hace este backdoor?
El atacante insertó una función al inicio del extension.js minificado de la extensión. Se ejecuta en cuanto el IDE carga el archivo, antes de que la extensión se active, así que no tienes que hacer clic en nada. Según el análisis de Phorion:
- Planta una llave de acceso. Agrega la llave Ed25519
svc-telemetrya~/.ssh/authorized_keysy crea el directorio y el archivo si no existen. - Intenta activar SSH. En macOS revisa Remote Login; en Windows intenta instalar OpenSSH Server. Sin permisos de administrador, ambos intentos suelen fallar: Phorion encontró un bug en la verificación de macOS y una ruta de shell incorrecta en el paso de Windows. Aun así, la llave y la persistencia quedan escritas. Phorion advierte que si activas Remote Login más adelante, el backdoor queda listo para usarse.
- Abre un reverse SSH tunnel. Se conecta hacia
134.209.82.225por el puerto 22 con una llave privada embebida (svc-telemetry-tun) y reenvía un puerto de vuelta al daemon SSH de tu equipo. Un bucle de reintentos mantiene el túnel activo aunque cierres el IDE. - Envía un beacon de reconocimiento. Un único POST al puerto 8099 con tu hostname, usuario, sistema operativo, directorio home, email global de Git, IP pública y los nombres (no los valores) de hasta 40 variables de entorno que contengan
KEY,TOKEN,SECRET,PASS,AWSoGCP. - Se vuelve persistente. En macOS instala un LaunchAgent de usuario con un nombre que imita un servicio de Apple. En Windows crea una tarea programada, con un script en la carpeta de Inicio como respaldo.
Cursor informa que trabajó con el proveedor de hosting para dar de baja el servidor del atacante y que este ya no funciona. Eso cierra la puerta por ahora, pero no elimina la llave ni la persistencia de tu equipo.
¿Por qué desinstalar la extensión no elimina el backdoor?
Nada del payload vive dentro de la carpeta de la extensión. La llave está en ~/.ssh, los scripts de persistencia en ~/.config y el LaunchAgent o la tarea programada en ubicaciones del sistema. Al quitar la extensión se borra extension.js, pero la llave, los scripts y el bucle del túnel se quedan donde el payload los dejó.
Qué buscar (según la lista de IOC de Cursor):
| Plataforma | Artefactos |
|---|---|
| macOS | Línea svc-telemetry en ~/.ssh/authorized_keys · ~/.config/.smt · ~/.config/.smtk · $TMPDIR/.stk_<10 hex> · ~/Library/LaunchAgents/com.apple.sysmond.plist (label com.apple.sysmond) |
| Windows | Línea svc-telemetry en %USERPROFILE%\.ssh\authorized_keys · %USERPROFILE%\.config\smt.cmd · %USERPROFILE%\.config\smtk · %TEMP%\.stk_<10 hex> · tarea programada SysMon · %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd |
Procesos que delatan el túnel: ssh -N -R '*:0:localhost:22' o autossh -M 0.
El payload también trae código para Linux (una entrada @reboot en crontab, /tmp/.stk_*), pero Cursor solo lista como afectados los builds de macOS y Windows.
¿Cómo eliminar el backdoor?
Usa los scripts de remediación de Cursor. Léelos antes de ejecutarlos: es buena práctica con cualquier cosa que llegue a raíz de un incidente de seguridad.
- macOS:
https://cursor.com/static/security/claude-code-extension/remediate-macos.sh, ejecútalo con tu usuario normal, no como root:bash remediate-macos.sh - Windows:
https://cursor.com/static/security/claude-code-extension/remediate-windows.ps1, ejecútalo en un PowerShell con privilegios elevados:powershell -ExecutionPolicy Bypass -File .\remediate-windows.ps1
Cursor indica que ambos scripts terminan con un código de salida distinto de cero si queda algo pendiente. Igual vuelve a correr el comando de verificación al final.
Si prefieres limpiar a mano, el orden que propone Phorion es:
- Detén el túnel: el bucle de reintentos en shell y cualquier proceso
sshoautosshque se conecte a134.209.82.225. - Elimina la persistencia: el LaunchAgent (macOS) o la tarea
SysMony el script de Inicio (Windows), además de los archivos.smty.smtk. - Borra la línea
svc-telemetrydeauthorized_keys, elimina el archivo temporal.stk_*y confirma que SSH o Remote Login no quedaron activados.
La guía de Cursor va más allá: aísla cualquier equipo que muestre que el payload se ejecutó y considera reinstalarlo desde cero, porque desinstalar la extensión puede no ser suficiente.
¿Qué credenciales debo rotar?
El beacon le envió al atacante los nombres de tus variables de entorno, no sus valores. Pero si SSH estaba accesible en tu equipo, o encuentras cualquier señal de un login entrante, asume que todo lo que esa cuenta de usuario podía leer está expuesto. Rota API keys, credenciales de nube (AWS, GCP), tokens de Git y tokens de sesión, empezando por los que coinciden con el filtro del beacon. Hazlo desde otro equipo de confianza, como recomienda Cursor.
Según Phorion, un login entrante a través del túnel aparecería como proveniente de localhost (127.0.0.1 o ::1) usando la llave svc-telemetry. Revisa tus logs de SSH en busca de esas entradas.
¿Qué garantizaba realmente el “Made by Anthropic”?
Nota de Grego
Por lo que se ha divulgado hasta ahora, nada falló en el pipeline de build de Anthropic. La falla estuvo en el marketplace, donde el nombre “Anthropic” junto a una extensión era una etiqueta, no una firma. Las extensiones al estilo VS Code no exigen firma criptográfica del publisher, y el marketplace de Cursor es un proxy montado sobre Open VSX con sus propias publicaciones agregadas. Ahí, el nombre del publisher te dice quién dice haber subido algo, no quién lo construyó.
Para un CTO la conclusión es concreta: una extensión de programación con IA corre con todos los permisos del usuario del developer, incluido su directorio SSH, sus tokens y su identidad de Git, y se actualiza sola. Trata las fuentes de extensiones como ya tratas los registros de paquetes. Fija versiones y usa listas de publishers permitidos donde el IDE lo permita, y vigila los procesos auxiliares del IDE que escriben en ~/.ssh: es exactamente el comportamiento que detecta Phorion.
¿Y tú? ¿Cómo verificas quién publicó una extensión antes de instalarla en tu IDE?
- Del VS Code Marketplace oficial
- Del marketplace de Cursor
- De Open VSX
- Prefiero otra opción (cuéntanos cuál)
Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.
Relacionado: GlassWorm Está en Tus Repos de Python Ahora — Qué Es, Cómo Funciona, Qué Hacer