Extensión de Claude Code con puerta trasera en Cursor: qué pasó, cómo detectarla y cómo limpiar el equipo

El 29 de octubre de 2026, entre las 2:27 y las 13:35 hora del Pacífico, quien instalara o actualizara la extensión de Claude Code desde el mercado de extensiones de Cursor recibió una versión que Anthropic no había publicado. El identificador era el legítimo, anthropic.claude-code, y la extensión funcionaba con normalidad. Antes de su código se ejecutaba, sin embargo, un cargador que dejaba en el equipo una clave SSH del atacante y mecanismos para sobrevivir a los reinicios, e intentaba abrir un túnel inverso hacia su servidor.

El aviso de seguridad de Cursor señala como maliciosas las versiones 2.1.312 y 2.1.313 para Windows y macOS. Según la compañía, citada por Help Net Security, hubo como máximo 5.000 usuarios expuestos, a los que contactará directamente. Anthropic sostiene que sus sistemas no fueron comprometidos y que sus canales oficiales, el Visual Studio Marketplace y Open VSX, no se vieron afectados. "Solo afecta a los usuarios de Cursor", resumió David Dworken, de Anthropic, en declaraciones que recoge The Hacker News.

¿Por dónde llegó la versión manipulada?

La versión manipulada llegó a través del mercado de extensiones que gestiona Cursor, y nadie ha explicado todavía cómo entró en él. Cursor deriva de VS Code, pero los términos del mercado de Microsoft no permiten usarlo en los derivados, así que estos se surten de Open VSX o de un catálogo independiente, como el de Cursor.

Ax Sharma, de Manifold Security, lo resumió en una frase que cita Help Net Security: "Comprobar el nombre del editor no sirve cuando el editor es el auténtico". En la jerga de los mercados de extensiones, el editor es la cuenta que publica; en este texto, el programa en el que se escribe código es el entorno de desarrollo o IDE.

Las primeras informaciones apuntaron a otros canales. Uno de los primeros informes, el de OpenSourceMalware, situó la versión en Open VSX, y un mensaje de una de sus cofundadoras habló de npm y del mercado de Microsoft. Socket repasó el registro de cambios de Open VSX, con 3.392 eventos desde el 27 de octubre, sin encontrar publicación ni retirada de la 2.1.313, que tampoco figura en npm. El informe original se corrigió después y dejó de señalar Open VSX como canal. Microsoft, en su análisis del código, confirma que el mercado de Visual Studio y los paquetes de npm no se vieron afectados.

La 2.1.312 complica el inventario. Socket registra su publicación en npm el 27 de octubre y sus compilaciones activas en Open VSX, mientras que Cursor la incluye entre las maliciosas de su catálogo. Todo indica que el mismo número puede corresponder a una versión limpia o a una manipulada según el mercado del que llegó, así que para cada equipo hay que saber qué versión tiene instalada y de dónde la descargó.

¿Cómo funcionaba el código añadido?

El código añadido recopilaba datos del equipo, abría un acceso SSH para el atacante y se aseguraba de volver a arrancar tras cada reinicio, todo con los permisos del usuario que abría el entorno. Microsoft describe la cadena paso a paso. Los errores se capturaban en silencio y la extensión seguía haciendo su trabajo, de modo que el desarrollador no notaba cambios.

¿Qué datos enviaba del equipo?

Al cargarse, el código recogía nombre del equipo, usuario, sistema operativo, arquitectura, directorio personal y de trabajo, y correo global de Git. Listaba también los nombres, sin los valores, de hasta 40 variables de entorno que contuvieran términos como KEY, TOKEN, SECRET, PASS o AWS. Saber que un portátil tiene un GITHUB_TOKEN o una clave de AWS no entrega el secreto, pero indica qué equipos interesan más cuando el túnel esté abierto. Según Cursor, el envío incluía también la IP pública, y todo salía por HTTP sin cifrar.

¿Para qué servían la clave SSH y el túnel inverso?

La clave y el túnel daban al atacante una vía de entrada al portátil desde fuera. El código comprobaba si el fichero authorized_keys contenía la marca svc-telemetry y, si no la encontraba, añadía una clave pública Ed25519 incrustada. Después intentaba activar el servicio SSH local y abría un túnel inverso hacia un servidor del atacante, con lo que el puerto 22 del portátil quedaba accesible desde ese servidor sin tocar el cortafuegos perimetral. En macOS y Linux recurría a autossh, o a ssh si faltaba; en Windows, a un bucle oculto de PowerShell que reintentaba la conexión cada 60 segundos.

Activar SSH exige privilegios de administrador, y Cursor explica que ese paso falla en la mayoría de los equipos macOS y Windows, salvo que el entorno se hubiera arrancado con esos privilegios. El análisis de Phorion que recoge Sophos atribuye esos fallos a errores de programación. Eso no resta urgencia a la limpieza. La clave y la persistencia se escriben igualmente, los datos del equipo se envían, y en un equipo con el acceso remoto por SSH ya activado la puerta trasera quedaba lista para usarse, según explicó Calum Hall, de Phorion, a Help Net Security.

¿Cómo sobrevivía a los reinicios?

Para relanzar el túnel, el cargador instalaba un mecanismo distinto en cada sistema. Los nombres imitan software de monitorización, y Microsoft aconseja inspeccionar la acción que ejecuta cada entrada antes de fiarse de cómo se llama. El código incluye la variante para Linux aunque Cursor solo cita paquetes afectados para Windows y macOS.

¿Por qué los controles habituales no lo detectaron?

Los controles habituales no lo detectaron porque la versión llegaba con el nombre del editor legítimo y actuaba dentro de un programa de confianza. El primer filtro que aplica una organización a una extensión es la reputación de quien la publica, y aquí el identificador era el de Anthropic. Una lista de permitidos por editor, como la que admite la política AllowedExtensions de Cursor, habría dejado pasar esta versión en toda empresa que tuviera aprobado al editor anthropic. Microsoft recomienda limitar las extensiones a editores aprobados, pero junto con un periodo de espera antes de instalar versiones nuevas.

Las comprobaciones basadas en firmas o en reputación tampoco tenían mucho a qué agarrarse. El código corre dentro del proceso de un IDE firmado, y sus acciones, como añadir una clave, crear una tarea programada o lanzar ssh, son las que un administrador de sistemas repite a diario. Microsoft documenta detecciones de comportamiento en Defender for Endpoint, entre ellas la actividad sospechosa originada en un editor de código, la adición sospechosa de una clave SSH y los túneles SSH sospechosos.

La actualización automática jugó a favor del atacante. Una extensión que se actualiza sola instala la versión nueva poco después de que aparezca, y en unas once horas la versión pudo llegar a 5.000 usuarios como máximo, según el recuento de Cursor.

Diez días antes, el 19 de octubre, otro caso dejó ver el mismo hueco en un canal distinto. Un atacante sustituyó los binarios de cinco versiones ya publicadas de la herramienta de línea de órdenes de OVHcloud en GitHub, junto con el fichero de sumas de verificación, para que las huellas cuadraran. Lo destapó en menos de dos horas la integración continua de un cliente que tenía fijado el SHA-256 del archivo, según la cronología de OpenSourceMalware.

Nombre, versión y dirección de descarga eran en ambos casos los esperados. En el de OVHcloud, el cliente que dio la alarma tenía una referencia de integridad guardada fuera del canal comprometido; en el de Cursor no consta que nadie la tuviera. Lo mismo se vio en las actualizaciones manipuladas de AOMEI Backupper. Frente a un ataque a la cadena de suministro dirigido al canal de distribución, la comprobación más fiable es la que se hace contra una referencia que el atacante no controla.

¿Cómo se detecta en la telemetría del EDR?

La búsqueda arranca con la lista de equipos que instalaron o actualizaron la extensión desde el mercado de Cursor el 29 de octubre. Las dos primeras consultas son de elaboración nuestra y las dos últimas adaptan las que publica Microsoft, que añade otras para las conexiones de red y los cambios en el LaunchAgent de macOS. Sus resultados son pistas para investigar, no prueba de compromiso.

Escrituras en authorized_keys iniciadas por procesos del entorno de desarrollo:

DeviceFileEvents
| where Timestamp > datetime(2026-10-29)
| where FileName in~ ("authorized_keys", "administrators_authorized_keys")
| where InitiatingProcessFolderPath has "cursor" or InitiatingProcessParentFileName has "cursor"
| project Timestamp, DeviceName, ActionType, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine

Procesos ssh o autossh que abren un túnel inverso hacia el puerto 22 local:

DeviceProcessEvents
| where Timestamp > datetime(2026-10-29)
| where FileName in~ ("ssh", "ssh.exe", "autossh")
| where ProcessCommandLine contains_cs "-R" and ProcessCommandLine contains "localhost:22"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

Tareas programadas de persistencia con el nombre documentado en Windows:

DeviceEvents
| where Timestamp > datetime(2026-10-29)
| where ActionType == "ScheduledTaskCreated"
| where tostring(AdditionalFields) has "SysMon" and tostring(AdditionalFields) has "smt"
| project Timestamp, DeviceName, AdditionalFields, InitiatingProcessFileName

Ficheros de persistencia y claves temporales en los tres sistemas:

DeviceFileEvents
| where Timestamp > datetime(2026-10-29)
| where FileName in~ ("com.apple.sysmond.plist", "sysmon.cmd", "smt.cmd", ".smt", ".smtk", "smtk") or FileName startswith ".stk_"
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, InitiatingProcessFileName

En la red, el indicador de compromiso más útil son las conexiones salientes a 134[.]209[.]82[.]225, el servidor del atacante según el aviso de Cursor, por el puerto 22 para el túnel y por el 8099 para el envío de datos. Cursor mantiene en ese aviso los hashes de los paquetes maliciosos y la huella de la clave añadida, y lo actualizó el 30 de octubre para actualizar indicadores y añadir la 2.1.312.

Hay un límite de calendario. La búsqueda avanzada de Defender conserva 30 días, así que revisar el 29 de octubre con esa herramienta solo es posible hasta el 28 de noviembre aproximadamente, salvo que la telemetría esté también en un SIEM. En los portátiles Linux sin agente, la comprobación pasa por el crontab del usuario y el fichero de claves.

Si el alcance no está claro, el trabajo se parece más a una campaña de búsqueda de amenazas que a una alerta suelta, porque hay que reconstruir qué hizo cada equipo desde que cargó la extensión.

¿Qué hay que hacer en un equipo afectado?

En un equipo afectado hay que conservar la evidencia, retirar la clave y la persistencia y, si hay indicios de acceso, rotar credenciales. Desinstalar la extensión no elimina la clave ni la persistencia, y tampoco instalar la 2.1.314, que Anthropic publicó en npm a las 00:12 UTC del 30 de octubre, según Socket. Cursor y Microsoft coinciden en que la persistencia vive fuera del directorio de extensiones, y que Cursor haya conseguido desactivar el servidor del atacante con su proveedor de alojamiento tampoco devuelve los equipos a su estado anterior.

• La evidencia se recoge antes de limpiar: el paquete de la extensión, los ficheros SSH modificados, las claves y scripts generados y la configuración de arranque.
• En authorized_keys, y en administrators_authorized_keys en Windows, se localiza la entrada svc-telemetry, se coteja su huella con la que publica Cursor y se retira solo esa línea.
• Cada tarea programada, LaunchAgent o entrada de crontab se juzga por la orden que lanza, y las confirmadas se borran junto con los ficheros .stk_.
• Los procesos ssh o autossh asociados se detienen, y tras un reinicio se comprueba que no reaparece ninguno.
• Si la telemetría sugiere acceso, las credenciales y sesiones alcanzables desde ese portátil se rotan desde otro equipo: claves de nube, tokens de GitHub y los secretos de las variables listadas. Muchas pertenecen a identidades no humanas cuyos permisos pueden ir más allá de lo que necesita el desarrollador.

Cursor ha publicado scripts de comprobación y limpieza para macOS, que se ejecuta con el usuario afectado, y para Windows, que requiere una consola de administrador. Microsoft recomienda leerlos antes de ejecutarlos, una precaución sensata con un script que llega en mitad de un incidente. Cursor y Microsoft contemplan reconstruir el equipo si no se puede recuperar la confianza en él. Para casos con acceso confirmado, un servicio de respuesta a incidentes ayuda a fijar hasta dónde llegó el atacante antes de dar el equipo por limpio.

¿Qué controles habrían frenado esta versión?

Habrían frenado esta versión los controles que separan el momento en que una versión aparece en el mercado del momento en que llega a los portátiles.

• Un periodo de espera antes de instalar versiones nuevas, que Microsoft recomienda expresamente para Cursor, habría dejado fuera la 2.1.313, que estuvo disponible unas once horas. Con la 2.1.312 dependería de si Cursor la sirvió como versión nueva o sustituyendo la ya publicada.
• Las actualizaciones automáticas de extensiones pueden desactivarse con el ajuste de usuario extensions.autoUpdate de VS Code y canalizarse por un proceso con revisión, aunque imponerlo como política en Cursor debe probarse antes.
• Fijar versiones exactas ayuda, con una salvedad. La documentación de VS Code permite atar extensions.allowed a versiones exactas, con una entrada que asocia anthropic.claude-code a la lista de versiones aprobadas, lo que habría bloqueado la 2.1.313, pero no una 2.1.312 servida desde el catálogo de Cursor. La documentación de Cursor describe AllowedExtensions con valores booleanos por editor o por extensión y no menciona versiones, así que el anclaje debe probarse antes en un equipo de pruebas.
• Un mercado privado o espejo interno, que Cursor permite configurar con ExtensionGalleryServiceUrl, deja pasar solo versiones revisadas.
• El inventario de entornos derivados cierra un hueco frecuente. Muchas organizaciones gobiernan las extensiones de VS Code y desconocen cuántos portátiles usan Cursor, Windsurf u otro derivado con catálogo y política independientes.

Las extensiones y agentes de programación con IA trabajan con permisos amplios sobre el código y las credenciales de quien los usa. Ya lo mostraron Plugin4Shell, que eludía el commit fijado en los plugins de agentes, y el gusano de npm que se instalaba en los hooks (ganchos de ejecución) de Claude Code. Este caso justifica tratar la estación de desarrollo como un activo de alto valor y aplicar las prácticas de DevSecOps también a las herramientas del desarrollador. Y hay un control más antiguo que todos los anteriores, que es dejar apagado el servicio SSH en los portátiles que no lo necesitan.

¿Se sabe ya cómo llegó la versión al mercado de Cursor?

No se sabe a 2 de noviembre, porque Cursor no ha publicado la causa. Su aviso indica que retiró la versión, cerró el mercado como precaución, lo reconstruyó, auditó los accesos, rotó claves y confirmó que ninguna otra extensión fue alterada. Mientras no explique cómo se publicó la versión, un mercado de extensiones operado por un tercero merece el trato de un proveedor, con su evaluación de riesgo de terceros, y no el de un espejo neutro del original.

Para un responsable de seguridad, la medida práctica es saber cuántas horas tarda una versión nueva de una extensión en llegar a los portátiles de la organización y quién la revisa por el camino.

Fuentes y atribución: este análisis se basa en información pública disponible a 2 de noviembre de 2026. Las fuentes principales son el aviso de seguridad de Cursor, el análisis de Microsoft Threat Intelligence, la revisión de registros de Socket y el informe de OpenSourceMalware, junto con la cobertura de Help Net Security, Sophos y The Hacker News, que recogen las declaraciones de Anthropic, Cursor y Phorion. La causa de la publicación maliciosa no se ha hecho pública, y la mención de Cursor y Anthropic no presupone un fallo en sus productos más allá de lo que ellos mismos han comunicado. Los datos sobre versiones afectadas e indicadores han cambiado desde la primera divulgación y pueden seguir cambiando.

Aviso: las consultas KQL, los indicadores y los ajustes de configuración son orientativos, deben adaptarse a cada entorno y probarse antes de usarlos en producción. Los indicadores proceden de terceros, pueden caducar y deben contrastarse con las fuentes originales.