Once horas de extensión troyanizada: el marketplace de Cursor sirvió un Claude Code con puerta trasera SSH
Durante casi doce horas, la extensión de Claude Code que se podía instalar desde el marketplace de Cursor traía una llave SSH que no era de Anthropic. Desinstalar la extensión no la borra de la máquina.
Qué pasó, con horas
El 29 de octubre de 2026, entre las 2:27 de la madrugada y la 1:35 de la tarde (hora del Pacífico), el marketplace de extensiones de Cursor sirvió una build modificada de anthropic.claude-code. La ventana sale de la notificación oficial de Cursor y coincide con el resumen de Ars Technica: casi doce horas con puerta trasera disponible para instalar. El 30 de octubre Cursor retiró las builds, publicó una versión corregida y cifró el alcance, y Microsoft Security publicó su propio análisis del código.
De las 2:27 a la 1:35, hora del Pacífico: casi doce horas de ventana
La duración es la parte incómoda del caso. No fue un paquete que estuvo unos minutos arriba: estuvo medio día siendo la versión que el marketplace entregaba a quien instalara o actualizara la extensión en ese intervalo.
Las builds 2.1.312 y 2.1.313, en macOS ARM y Windows x64
La versión señalada en la notificación de Cursor es la 2.1.313, con builds darwin-arm64 y win32-x64. Cryptopolitan menciona también la 2.1.312. El código estaba escrito para funcionar en Windows, macOS y Linux, según Ars Technica, aunque las builds publicadas en el marketplace fueran las dos anteriores.
Lee también
Hasta 5.000 usuarios expuestos, según Cursor
Expuestos no es lo mismo que infectados. Las 5.000 cuentas son el techo de usuarios que pudieron descargar la versión, no la cantidad de equipos donde el túnel llegó a establecerse. Cursor recomienda aplicar la remediación aunque el túnel no se haya completado.
Cómo entró el paquete: lo que no se ha explicado
Cursor dijo a OpenSourceMalware que la extensión "experimentó alguna forma de compromiso". El mecanismo por el que la build modificada llegó al marketplace no está explicado públicamente. Tampoco aparece una declaración propia de Anthropic en la cobertura disponible: lo que hay son comunicados y análisis de Cursor y de Microsoft.
Qué hacía el código malicioso
El payload no era un robo de tokens silencioso. Era acceso remoto persistente, montado en cuatro pasos que se ejecutan en orden.
Un cargador de 66 líneas al principio de extension.js
Los análisis de OpenSourceMalware y CybersecurityNews describen un bloque de unas 66 líneas insertado al inicio de extension.js. Va antes de la inicialización legítima, así que corre primero: al arrancar el editor y otra vez al abrir la vista webview de la extensión.
Una llave llamada svc-telemetry en ~/.ssh/authorized_keys
El código añade al final de ~/.ssh/authorized_keys una llave pública controlada por el atacante, etiquetada svc-telemetry para que parezca un componente de telemetría del propio editor. Con esa llave en el archivo, el servidor SSH acepta la conexión sin contraseña y sin que nadie note nada raro en la lista.
Túnel inverso al 134.209.82[.]225 y un POST con los datos del equipo
Después intenta activar el servicio SSH local y abre un túnel inverso hacia el puerto 22 de 134.209.82[.]225 con el usuario tunnel, apuntando al puerto 22 de la máquina. También envía datos del host por HTTP al puerto 8099 de esa misma IP y prueba el 127.0.0.1:8099. Un túnel inverso conecta desde tu equipo hacia fuera: no necesita que abras ningún puerto en el router, que es justo lo que lo hace pasar desapercibido en una red doméstica u oficina.
Persistencia: reconexión cada 60 segundos y verificación de host desactivada
El túnel desactiva la comprobación de identidad del servidor y reintenta cada minuto. La combinación es lo que lo vuelve persistente: si el proceso muere, vuelve a levantarse; si el servidor remoto cambia de llave, no se queja.
El detalle de macOS que pudo limitar el daño
Un análisis de Phorion recogido por explainx señala un fallo en la variante de macOS que pudo reducir el daño real en esos equipos. Es un matiz de terceros, no una confirmación oficial: conviene tratarlo como indicio y no como hecho probado.
Por qué esto importa más que el incidente
El caso concreto se resuelve con higiene y rotación de credenciales. Lo que no se resuelve tan fácil es la razón por la que funcionó.
El marketplace es el nuevo npm: un clic y confías en la identidad del paquete
Instalar una extensión es ejecutar código de un tercero con tus permisos, dentro del editor que tiene abierto tu proyecto, tus claves y tu terminal. El marketplace de un editor hace lo mismo que hacía npm: resuelve el nombre del paquete, comprueba que la cuenta existe y te lo entrega. Es el mismo modelo de confianza que ya nos costó caro en Plugin4Shell, donde el problema no era el código de un plugin, sino quién lo aprobaba.
El nombre del publicador no es una firma del fabricante
El paquete se llamaba anthropic.claude-code y colgaba de la cuenta de Anthropic. Eso no es una firma criptográfica del fabricante ni una revisión de contenido: es un identificador de cuenta en un registro. Cuando esa cuenta o el canal de publicación se ven comprometidos, el nombre sigue intacto y el contenido ya no.
2026 ya traía precedentes: GlassWorm, Nx Console y el caso de GitHub
GlassWorm en octubre, con temas falsos de VS Code en Visual Studio Marketplace y Open VSX; Nx Console comprometido en mayo, con 2,2 millones de instalaciones; y una brecha en GitHub a través de una extensión envenenada que alcanzó unos 3.800 repositorios internos. Tres vectores, un mismo patrón: el canal de distribución de las herramientas de desarrollo es parte de la superficie de ataque.
Cómo saber si te tocó
Revisar la versión instalada y cuándo se actualizó
En Cursor, la vista de extensiones muestra la versión instalada. Desde la terminal del editor, code --list-extensions --show-versions devuelve nombre y número. Si aparece 2.1.313 o 2.1.312 con fecha del 29 de octubre, aplica la remediación completa aunque no encuentres nada más.
Buscar la llave y los procesos del túnel en la máquina
Lee las últimas líneas de ~/.ssh/authorized_keys buscando una entrada con el comentario svc-telemetry. Después revisa los procesos en busca de ssh -R, que es la forma de un túnel inverso. En Windows el archivo vive en %USERPROFILE%\.ssh\authorized_keys.
Revisar conexiones salientes al 134.209.82[.]225 y el log de SSH
Cualquier conexión saliente al puerto 22 o al 8099 de esa IP desde un equipo de desarrollo es una señal. El registro del servicio SSH delata los intentos de activarlo si el sistema no lo tenía encendido antes.
Qué hacer, en orden
1. Recoger evidencia antes de borrar nada
Copia authorized_keys, la lista de procesos y los registros de SSH a otro medio antes de tocar el equipo. Si borras primero, pierdes la posibilidad de saber qué entró y qué se llevó.
2. Sacar la llave de authorized_keys y cerrar el túnel
Elimina la línea de svc-telemetry, termina los procesos del túnel y confirma que no vuelven a levantarse. Revisa también las entradas de arranque automático, porque Microsoft advirtió que quitar la build del marketplace no borra los artefactos ya presentes en la máquina.
3. Rotar todo lo que vivía en esa máquina
Claves SSH, tokens de Git, credenciales de nube, llaves de API en variables de entorno y sesiones de navegador con acceso a paneles. Si el equipo tuvo acceso a producción, el alcance de la rotación es el de todo lo que ese acceso permitía.
4. Reinstalar desde la fuente oficial y fijar la versión
Instala desde el canal oficial y fija la versión, igual que fijas las dependencias de un proyecto. Aquí el contraste con PHP2Shell es útil: en ese caso el parche era del proveedor y actualizar resolvía el problema. En este, actualizar no limpia nada de lo que ya se instaló.
Qué cambiar en tu forma de trabajar
Fijar versiones y mirar qué cambia en una actualización de extensión
Las extensiones se actualizan solas y casi nadie lee el cambio. Fijar la versión y revisar antes de subir convierte una actualización silenciosa en una decisión tuya.
Menos credenciales de producción en el portátil de desarrollo
El equipo de desarrollo es el que tiene las llaves de todo. Reducir lo que vive ahí, o moverlo a un gestor de secretos con caducidad, limita el daño de cualquier incidente futuro sin depender de detectar este.
El equipo de desarrollo también es superficie de ataque
La cadena de suministro de las herramientas de código dejó de ser un tema de infraestructura. Los agentes y editores con acceso al proyecto son parte del perímetro, y merecen la misma revisión que un servidor expuesto.
Conclusión
La lección no es desconfiar de Claude Code ni dejar de usar agentes. Es que instalar una extensión significa ejecutar código de un tercero con tus permisos, y esa decisión merece la misma revisión que un npm install en un proyecto ajeno. Si instalaste la extensión desde ese canal el 29 de octubre, revisa primero y rota después; el resto del hilo de noticias de tecnología sigue en el blog.
