Extensión troyanizada de Claude Code en el marketplace de Cursor

¿Fue vulnerada Anthropic? Es la pregunta que llena hoy todos los Slack de seguridad, y la respuesta, según lo que se ha podido demostrar, es que no. Lo que realmente ocurrió es, en cierto modo, peor para el resto: alguien subió una versión troyanizada de la extensión oficial de Claude Code de Anthropic al marketplace de Cursor, bajo la identidad real del editor de Anthropic, y hasta 5.000 desarrolladores la instalaron. No hizo falta comprometer a Anthropic. El modelo de confianza hizo el trabajo del atacante gratis.

La versión maliciosa, la 2.1.313, incluía una puerta trasera SSH persistente dirigida a Windows, macOS y Linux. Según The Hacker News, estuvo en el marketplace de Cursor unas 11 horas el 29 de octubre, desde aproximadamente las 2:27 a. m. hasta la 1:35 p. m. PT, antes de que Cursor cerrara todo el marketplace para retirarla. Anthropic ha publicado desde entonces una versión limpia, la 2.1.314, en Open VSX y en el marketplace de Visual Studio Code de Microsoft, y no se sabe que ninguno de los dos haya resultado afectado.

No fue una brecha en Anthropic. Y eso no es tan tranquilizador como suena.

Anthropic se apresuró a marcar la diferencia. Felix Rieseberg, miembro de su equipo técnico, dijo que la empresa trabaja con Cursor, pero que «no fue un compromiso de los sistemas de Anthropic ni de los portátiles de sus empleados», y añadió que un actor malicioso usó el acceso al marketplace de Cursor para publicar una copia manipulada que Anthropic no construyó, según informa The Register. Cursor, por su parte, afirmó que la versión maliciosa «no fue desarrollada por Anthropic» y que como máximo se vieron afectados 5.000 usuarios.

Bien. Pero aquí está la parte que debería preocuparte más que la cuestión de la atribución: los atacantes no necesitaron una extensión falsa. Distribuyeron el malware como la versión 2.1.313 bajo el ID legítimo de la extensión, anthropic.claude-code. Jenn Gile, cofundadora de OpenSourceMalware, explicó a The Hacker News que el paquete principal de JavaScript tenía un cargador malicioso de 66 líneas insertado antes del código legítimo. Cada control que un desarrollador podría aplicar (verificar el editor, verificar el nombre, comprobar que es la versión oficial) habría pasado. Eso no es un problema de Cursor ni de Anthropic. Es el modelo del marketplace mostrándote lo que vale.

Sigue sin conocerse cómo el atacante obtuvo acceso de publicación. Ni Cursor ni Anthropic lo han explicado. Cursor dice que retiró el paquete al detectarlo, cerró el marketplace «por precaución», revisó otras extensiones, rotó sus propias claves y trabajó con un proveedor de nube para bloquear el servidor del atacante. Todo sensato. Ninguna de esas medidas responde a cómo estaba abierta la puerta en primer lugar.

Qué hacía realmente el implante y dónde se quedó corto

La carga útil era una verdadera puerta trasera, no un robo rápido de datos. Al activarse (tras el inicio de VS Code y cuando se abre la webview de la extensión) añadía una clave controlada por el atacante al archivo ~/.ssh/authorized_keys de la víctima, etiquetada convenientemente como svc-telemetry para que pareciera rutinaria. Después intentaba habilitar el acceso SSH en las tres plataformas de escritorio, abría un túnel inverso hacia 134.209.82[.]225, instalaba persistencia como tarea programada, entrada de crontab o LaunchAgent según el sistema operativo, y enviaba datos de reconocimiento del equipo a 134.209.82[.]225:8099/beacon mediante HTTP sin cifrar.

Ahora, la parte que importa menos de lo que sugieren los titulares. Habilitar el servicio SSH requiere privilegios de administrador, que la extensión no tenía en la mayoría de equipos macOS y Windows; el propio análisis de Cursor reconoce que el paso del túnel falló allí. Así que el desenlace cinematográfico, un atacante entrando directamente en cinco mil equipos de desarrollo, en gran medida no ocurrió. Pero «en gran medida» hace mucho trabajo. El implante igualmente colocó la clave, instaló la persistencia y llamó a casa en todos los lugares donde se ejecutó, y los escritorios Linux con SSH ya activado son otra historia. El consejo de Cursor es contundente: sigue los pasos de remediación de todos modos. Y ojo con esto: instalar la 2.1.314 no elimina la persistencia. Si te actualizaste automáticamente durante la ventana mala, tienes que limpiar, no solo actualizar.

La lista de reconocimiento te dice qué buscaba el operador:

• Dirección IP pública (mediante api.ipify[.]org), nombre de host y usuario local
• Sistema operativo y arquitectura de CPU, directorio personal y directorio de trabajo
• Correo global de Git, obtenido con git config --global user.email
• Nombres de hasta 40 variables de entorno que contengan KEY, TOKEN, SECRET, PASS, AWS o GCP

El investigador de seguridad Paul McCarty señaló que los valores de las variables no se enviaron en la baliza inicial, pero solo con los nombres se puede deducir qué proveedores de nube y sistemas de CI utiliza la víctima, y un acceso SSH exitoso permitiría al operador leer los valores directamente. Los equipos de desarrolladores son piñatas de credenciales. Todo el que está en este sector lo sabe; los atacantes lo presupuestan.

Cinco mil desarrolladores, once horas, una sola opción de actualización automática

Hagamos la aritmética del coste de oportunidad, porque es lo que tu consejo de administración acabará preguntando. Once horas de exposición. Como máximo 5.000 instalaciones, según Cursor. La observación de Gile es la clave: cualquiera con la extensión configurada para actualizarse automáticamente pudo ejecutar el malware en cuanto llegó. La actualización automática es la opción por defecto en la mayoría de entornos de desarrollo porque colectivamente decidimos que la fricción cuesta más que el riesgo. Ayer llegó esa factura.

Y no es una factura aislada. Poco más de una semana antes, un atacante desconocido reemplazó los binarios de cinco versiones publicadas de la CLI oficial de OVHcloud por malware robador de secretos, subido a través de la cuenta de GitHub secuestrada de un colaborador legítimo de OVH, una cuenta tomada en marzo como parte de la operación GlassWorm. Ya hemos cubierto el mismo patrón desde otro ángulo: LiteLLM 1.107.0 recibió una puerta trasera mediante tokens de GitHub robados, y los agentes de programación con IA pueden ser manipulados por un único archivo en una carpeta de Descargas. La cadena de suministro de las herramientas de IA no es objetivo por estar de moda. Lo es porque los desarrolladores la ejecutan con credenciales amplias, en equipos que pueden alcanzar todo, y la actualizan sin mirar.

La solución cuesta menos que el incidente

Mi veredicto, y es el poco de moda: este incidente fue sobrevivible, pero la clase de incidente no lo es. El atacante falló en la escalada de privilegios, Cursor retiró el paquete rápido y el radio de impacto se quedó en unos miles. La próxima vez el cargador comprobará si ya hay un servicio SSH en ejecución, o la ventana se mantendrá abierta un fin de semana. Nada de eso lo puedes controlar. Lo que sí puedes controlar es si las herramientas de tus desarrolladores se actualizan solas desde un registro que no operas, bajo una identidad que cualquiera con el acceso adecuado puede usar.

La remediación para los afectados está clara: aislar los equipos, eliminar la clave SSH no autorizada y los mecanismos de persistencia, y rotar credenciales y sesiones. Para el resto, el control más barato es el que llevas posponiendo: fijar versiones de extensiones, revisar las actualizaciones antes de desplegarlas y tratar las estaciones de trabajo de desarrollo como lo que son: activos que contienen credenciales y están cerca de producción. La pregunta para tu próxima reunión del consejo no es si Anthropic fue vulnerada. Es por qué un binario que no has firmado puede aterrizar en una máquina que guarda tus claves de nube. Responde eso antes de que lo haga otro.