Extensión de Claude para Cursor con backdoor SSH: qué falló en la confianza y qué revisar

La extensión de Claude para Cursor con un backdoor SSH llegó a los equipos de desarrollo como una actualización normal. Se publicó con la identidad del editor oficial y no como una imitación. Ese detalle convierte el incidente en algo más que una noticia puntual.

Para un equipo técnico, no basta con saber si alguien instaló la versión 2.1.313. Conviene entender por qué se pudo explotar una confianza tan razonable como «es la extensión oficial» y qué controles faltan para que la próxima vez no dependa de la suerte.

Una actualización con identidad legítima intentó instalar una puerta trasera persistente

Según The Hacker News, una versión troyanizada de la extensión oficial de Claude Code, la 2.1.313, se distribuyó a través del mercado de extensiones de Cursor. Llegó como actualización legítima y con el identificador del editor original, anthropic.claude-code, en lugar de como una extensión falsa aparte [1]. Su objetivo era dejar una puerta trasera SSH persistente en los equipos donde se instalaba. Cursor llegó a cerrar temporalmente su mercado para retirar el paquete [1].

Help Net Security atribuye el hallazgo a Phorion, una firma de seguridad especializada en macOS [2]. Atlabyte añade que también participaron investigadores de OpenSourceMalware [3]. Las fuentes coinciden en la mecánica: un cargador malicioso de JavaScript insertado al principio del archivo principal de la extensión, con el resto del código legítimo sin cambios. Ese cargador se ejecuta en cuanto se carga la extensión, sin que el usuario tenga que interactuar con ella [2] [3].

Según el análisis que recoge The Hacker News, una vez activo, el código añade una clave SSH controlada por el atacante al archivo de claves autorizadas del usuario. La etiqueta como «svc-telemetry» para que parezca inofensiva [1]. Después intenta abrir un túnel inverso hacia el servidor del atacante y establecer persistencia en cada sistema. En Windows intenta crear una tarea programada y, si falla, recurre a la carpeta de inicio. En Linux añade una entrada de crontab y en macOS instala un LaunchAgent [1] [2]. Además, envía al operador datos del equipo, como el nombre de host, el usuario, el sistema operativo, el correo de Git y los nombres de las variables de entorno que parecen contener claves o tokens. Envía esos nombres, pero no sus valores [1] [2].

No es un script curioso, sino un intento de acceso interactivo de largo plazo a la máquina de un desarrollador.

Qué está confirmado y qué sigue sin explicarse

Algunos datos ya están documentados. Según Atlabyte, la versión maliciosa estuvo disponible el 29 de octubre de 2026 entre las 2:27 y las 13:35, hora del Pacífico [3]. Esa ventana coincide con la que comunicó Cursor y que recoge The Hacker News [1]. Cursor ha fijado un máximo de usuarios afectados y ha anunciado que contactará directamente con ellos [1] [2]. La empresa sostiene también que Anthropic no desarrolló esa versión [1] [3]. Por su parte, Anthropic ha publicado la versión 2.1.314 en Open VSX y en el Visual Studio Marketplace de Microsoft [1].

Hay un factor que limita el daño, aunque no lo anula. Cursor explica que activar el servicio SSH local requiere permisos de administrador, y la extensión no los tiene en la mayoría de equipos macOS y Windows. En esos casos, el atacante no habría podido entrar por el túnel [1]. Phorion relaciona el fallo en macOS con una comprobación mal programada. Su consejero delegado, Calum Hall, advierte de que ese error no es una defensa. En un Mac con el inicio de sesión remoto ya activado, o en uno que lo active más adelante, la puerta trasera queda lista para usarse [2]. Cursor colaboró además con el proveedor cloud que alojaba el servidor del atacante para desconectarlo. Así cortó tanto el túnel como el envío de datos [2].

Falta, sobre todo, saber cómo se publicó la actualización con la identidad del editor legítimo. Ni The Hacker News ni Atlabyte han podido explicarlo [1] [3]. Atlabyte señala que seguirá atento a si se aclara el método y a si llegaron a comprometerse sistemas de Cursor o de Anthropic [3]. Mientras no haya una explicación oficial, cualquier hipótesis sobre el vector o sobre la autoría es especulación. Conviene contrastar los detalles con el aviso de seguridad de Cursor y con el análisis de Phorion.

La confusión inicial con Open VSX ayuda a entender de dónde llegan estas extensiones

Las primeras informaciones no coincidían sobre el canal. Help Net Security publicó que Phorion había localizado el paquete en Open VSX, el mercado de código abierto de extensiones para VS Code que gestiona la Eclipse Foundation [2]. El propio medio añadió después una actualización en la que Ax Sharma, de Manifold Security, discute que la versión de Open VSX estuviera comprometida [2]. The Hacker News corrigió su información: el incidente se ha rastreado hasta el mercado de Cursor, sin pruebas de que llegara a Open VSX ni al mercado oficial de Microsoft [1]. Atlabyte recoge igualmente que se confirmó que Cursor fue la única fuente [3].

Aun así, la confusión ilustra algo relevante. Help Net Security explica que los términos de uso del Visual Studio Marketplace lo limitan a productos de Microsoft. Por eso, los editores construidos sobre el código abierto de VS Code, como Cursor o Windsurf, no pueden usarlo y recurren a otros mercados [2]. Una misma extensión, con el mismo nombre, puede llegar al desarrollador por canales distintos según el editor que use.

Si en tu empresa conviven VS Code, Cursor y otros editores derivados, tienes que vigilar varios mercados, no uno. Ese es el terreno de la gestión del riesgo en la cadena de suministro de software. En este contexto, conviene saber qué software de terceros entra en la organización, por qué vía y con qué garantías.

El nombre del editor oficial dejó de ser una señal fiable de confianza

Aquí está el núcleo del caso. La actualización llegó con la identidad legítima del editor [1] y, según Cursor, no la creó Anthropic [3]. Ax Sharma lo resume en la actualización de Help Net Security: no había ninguna suplantación que detectar. Comprobar el nombre del editor no sirve cuando el editor es real, y lo que ayuda es vigilar el comportamiento [2]. En The Hacker News, Jenn Gile, cofundadora de OpenSourceMalware, añade otro factor. Aunque la versión se retiró muy rápido, pudo recibirla cualquiera que tuviera activada la actualización automática [1].

De ahí se extrae una lectura incómoda: no conviene confiar únicamente en una política de «instalar solo extensiones oficiales». No se trata de culpar a Cursor, a Anthropic ni a los desarrolladores que actualizaron. La actualización se distribuyó con la identidad legítima del editor y, aun así, contenía código malicioso.

Por eso, la confianza en el editor necesita controles propios que la complementen. Hay que saber qué versión está instalada en cada equipo, decidir cuándo se actualiza y poder reaccionar en horas, no en semanas.

Qué revisar en los puestos de desarrollo: versión instalada, claves SSH e inventario de extensiones

Los pasos siguientes son una orientación general. Para las comprobaciones concretas, sigue los comandos y los scripts de limpieza publicados por Cursor. Usa también los indicadores de compromiso compartidos por Cursor y Phorion [2].

1. Identifica la exposición. Comprueba si algún equipo con Cursor instaló la versión 2.1.313 o se actualizó a ella. Verifica también si la fecha cae dentro de la ventana del 29 de octubre de 2026 que indican las fuentes [1] [3].
2. Revisa las claves SSH autorizadas. Busca en el archivo de claves autorizadas una entrada etiquetada como «svc-telemetry», como recomiendan Help Net Security y Atlabyte [2] [3]. Phorion sugiere revisar también los registros de SSH en busca de inicios de sesión desde localhost con esa clave [2].
3. No te quedes en desinstalar. Phorion advierte de que desinstalar la extensión no elimina la puerta trasera. Cursor señala que el código deja scripts independientes que siguen ejecutándose [2]. Hay que eliminar la clave no autorizada y los mecanismos de persistencia [1].
4. Trata el equipo como comprometido si hay indicios. Cursor aconseja aislar las máquinas afectadas y valorar su reconstrucción. También recomienda rotar, desde un sistema de confianza, las credenciales y sesiones a las que pudieran acceder [2].
5. Fija una política para lo que viene. Mantén un inventario de extensiones por equipo y una lista de extensiones permitidas. En los puestos críticos, revisa las actualizaciones en lugar de aplicarlas automáticamente y registra lo que se instala. Esto es buena práctica general, no una recomendación de las fuentes.

Puede que tu organización esté desplegando asistentes de código a escala y tengas dudas sobre el alcance. En ese caso, una consultoría para revisar la seguridad de tus herramientas de IA para desarrollo puede ayudar a decidir qué comportamientos vigilar en esos puestos y cómo responder cuando algo se sale de lo esperado.

Adoptar asistentes de código con IA exige gobernar también lo que se instala a su alrededor

Este caso no va de un modelo de IA que se equivoca ni de una fuga de datos de entrenamiento. Va de algo más prosaico: una extensión que lleva el nombre del editor oficial puede convertirse en la puerta de entrada. Según Atlabyte, la extensión de Claude Code añade un asistente de IA a los editores compatibles para ayudar a escribir y depurar código [3]. En este incidente, el código malicioso pudo añadir una clave SSH al archivo de claves autorizadas del usuario.

La idea que conviene llevarse es sencilla: la confianza en las herramientas de desarrollo con IA no se presupone. Se gestiona con inventario, control de versiones y revisión periódica de claves. El incidente duró unas horas, pero la decisión sobre quién aprueba, quién inventaría y quién revoca lo que se instala es permanente. Para las empresas que están incorporando asistentes de código, la gobernanza de la IA no termina en el modelo ni en los datos. Alcanza también a las extensiones, a las claves SSH de quienes las usan y a los mercados desde los que se instalan.

Si quieres ordenar ese perímetro, puedes consultar la solución de gobernanza de la seguridad de la IA.