osky

Extensión falsa de Claude Code en el marketplace de Cursor dejaba una puerta trasera SSH: qué revisar

Extensión falsa de Claude Code en el marketplace de Cursor dejaba una puerta trasera SSH: qué revisar
Sección
IA

Si usas Cursor y tienes instalada la extensión de Claude Code, para lo que estés haciendo y revisa tu máquina. El 29 de octubre de 2026, durante unas once horas, el Marketplace de extensiones de Cursor distribuyó una copia alterada de Anthropic.claude-code, versiones 2.1.312 y 2.1.313 para macOS y Windows, que intenta dejar una puerta trasera por SSH en el equipo. Cursor ya retiró esas versiones y tumbó el servidor del atacante, pero hay un detalle que lo cambia todo: desinstalar la extensión no limpia el equipo. El código malicioso deja scripts de persistencia que siguen corriendo por su cuenta.

Qué pasó

La empresa de seguridad Phorion detectó el paquete y publicó un análisis técnico. Después Cursor publicó su aviso de seguridad. Según Cursor, la versión maliciosa estuvo disponible entre las 2:27 am y la 1:35 pm, hora del Pacífico, del 29 de octubre. La empresa aclara que esas versiones "no fueron desarrolladas por Anthropic".

Felix Rieseberg, de Anthropic, lo confirmó en Hacker News: no hubo intrusión en los sistemas ni en las laptops de empleados de Anthropic. Alguien usó acceso al marketplace de Cursor para publicar una copia manipulada de la extensión. Según él, las versiones de los canales oficiales de Anthropic no están afectadas y el problema solo toca a usuarios de Cursor.

Lo que ninguno de los avisos explica todavía es cómo consiguió el atacante ese acceso. Cursor dice que auditó los accesos, confirmó que ninguna otra extensión fue alterada, rotó sus llaves, reconstruyó el marketplace y lo volvió a poner en línea. También lo apagó por completo un rato, por precaución.

Qué hace el código malicioso

De acuerdo con Phorion, el atacante insertó un bloque de código al inicio del archivo extension.js. El resto del paquete es la extensión normal, con su interfaz y sus funciones. Ese bloque se ejecuta en cuanto el editor carga el archivo, antes de la función activate: no necesitas abrir ni usar la extensión para que se dispare. La cadena tiene cuatro pasos:

  1. Llave SSH plantada. Agrega una llave pública Ed25519 del atacante a ~/.ssh/authorized_keys, con el comentario svc-telemetry.
  2. Servidor SSH local. Intenta encenderlo: en Linux con systemctl, en macOS con systemsetup y en Windows instalando OpenSSH Server con PowerShell.
  3. Túnel inverso. Abre una conexión SSH de salida hacia el servidor del atacante con -R *:0:localhost:22. Así el operador puede regresar por ese túnel y entrar al puerto 22 de tu máquina, aunque estés detrás de un NAT o de un firewall que no acepta conexiones entrantes. El túnel se reintenta cada 60 segundos y sobrevive aunque cierres el editor.
  4. Persistencia. En macOS instala un LaunchAgent disfrazado de componente de Apple (~/Library/LaunchAgents/com.apple.sysmond.plist). En Windows intenta crear una tarea programada SysMon como SYSTEM y, si no puede, deja un sysmon.cmd en la carpeta de Inicio. El código también trae lógica para Linux con una entrada @reboot en el crontab.

Diagrama de los cuatro pasos de la extensión falsa: código al cargar, llave SSH plantada, túnel inverso y persistencia, más el reporte al atacante y los pasos de limpieza

Además manda un reporte al atacante con hostname, usuario, sistema operativo, arquitectura, carpeta personal, directorio de trabajo, correo global de Git, IP pública y hasta 40 nombres de variables de entorno que contengan KEY, TOKEN, SECRET, PASS, AWS o GCP. Phorion subraya que manda los nombres, no los valores. Aun así, eso le da al atacante un inventario de qué máquinas tienen credenciales de nube o tokens de API y cuáles conviene atacar primero.

La buena noticia (con asterisco)

El malware tiene errores. Phorion encontró que en macOS el script revisa si el acceso remoto está apagado con systemsetup -getremotelogin sin permisos de administrador. Como usuario normal, ese comando responde con un mensaje de error en lugar de "Off", así que el script nunca intenta encenderlo. En Windows, la instalación de OpenSSH pasa por una función que llama a /bin/sh, algo que no existe en una instalación estándar.

Cursor llega a la misma conclusión: salvo que hayas abierto el editor con privilegios de administrador, el paso de encender SSH falla y el atacante no pudo entrar por el túnel. La empresa también trabajó con el proveedor de nube que alojaba el servidor del atacante para darlo de baja, así que el túnel y el reporte ya no llegan a ningún lado.

El asterisco: aunque falle el SSH, la llave del atacante sí quedó en tu authorized_keys, la persistencia sí quedó instalada y tus datos sí se enviaron. Si tu Mac ya tenía activado el Acceso remoto, o lo activas después, la puerta queda lista. Por eso Cursor pide seguir los pasos de limpieza de todos modos.

Cómo saber si te pegó y cómo limpiarlo

Aplica si instalaste o actualizaste a la 2.1.312 o 2.1.313 desde el marketplace de Cursor, en macOS o Windows, dentro de esa ventana del 29 de octubre. La prueba rápida que publica Cursor para macOS es:

grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "svc-telemetry key found" || echo "No key found; machine not impacted"

Para Windows hay una versión en PowerShell en el aviso oficial. Si aparece la llave, tu equipo está comprometido. Cursor recomienda:

  • Aislar el equipo si hay evidencia de que el código se ejecutó.
  • Correr el script de limpieza de Cursor: remediate-macos.sh como tu usuario, sin root, o remediate-windows.ps1 como administrador. Quitan la extensión, la persistencia, los procesos del túnel y la llave.
  • Evaluar si conviene reinstalar el equipo desde cero.
  • Rotar credenciales y sesiones accesibles desde esa máquina, haciéndolo desde un equipo de confianza. Cursor advierte que, aunque el malware solo recolectó nombres de variables, eso no descarta que alguien haya entrado después por la puerta trasera.

Para limpiar a mano, Phorion lista los artefactos: ~/.config/.smt, ~/.config/.smtk, los archivos .stk_* en la carpeta temporal, el LaunchAgent com.apple.sysmond, la tarea SysMon o el sysmon.cmd de Inicio, y cualquier proceso ssh o autossh con -R *:0:localhost:22. Si tu equipo sí tenía SSH activo, revisa los logs de inicio de sesión: un acceso por el túnel aparece como si viniera de localhost usando la llave svc-telemetry. No pongo aquí la IP del atacante ni los hashes: están completos y actualizados en los dos avisos de abajo.

Mi lectura

Este caso no rompe ningún modelo de IA. Rompe la confianza en la tienda. Los editores basados en VS Code, como Cursor, tienen sus propios marketplaces, y en la discusión de Hacker News quedó claro que mucha gente daba por hecho que "hecho por Anthropic" en la tienda de Cursor significaba que Anthropic había firmado ese paquete. Este incidente muestra que no necesariamente: alguien con acceso al marketplace pudo publicar una versión con el nombre oficial.

Una extensión de un asistente de código es el disfraz perfecto: corre con tus permisos, ve tu código, tu terminal y tus variables de entorno, y nadie se extraña de que haga conexiones de red. Lo que esto significa en la práctica:

  • Trata las extensiones como dependencias de producción, no como apps de celular. Si trabajas en equipo, una lista de extensiones aprobadas ya no suena exagerada.
  • Desactiva las actualizaciones automáticas de extensiones en máquinas con credenciales delicadas, o al menos revisa qué cambió antes de aceptar una versión nueva.
  • No dejes tokens de producción como variables de entorno globales en tu laptop de desarrollo. Ese filtro de KEY|TOKEN|SECRET no está ahí por casualidad.
  • Vigila ~/.ssh/authorized_keys en tu propia máquina. Casi nadie lo revisa en una laptop, y por eso es tan buen escondite.

Falta que Cursor explique cómo entró el atacante. Mientras eso no se sepa, la pregunta incómoda no es si estaba la extensión de Claude Code, sino qué otra extensión "oficial" podría ser la siguiente.

Fuentes