Claude Code falso en Cursor afectó a 5.000 usuarios

Una copia manipulada de la extensión oficial de Claude Code estuvo disponible unas 11 horas en la tienda de extensiones de Cursor el 29 de octubre y llegó a hasta 5.000 usuarios. El código intentaba instalar una puerta trasera por SSH en el equipo del desarrollador. Para cualquier founder que programa con asistentes de IA, la lección no es sobre modelos: es sobre de dónde bajas el software.

Qué pasó exactamente en la tienda de Cursor

Alguien publicó en la tienda de Cursor dos versiones trucadas de la extensión de Anthropic: la 2.1.312 y la 2.1.313, para Windows y macOS. Según Cursor, estuvieron disponibles entre aproximadamente las 2:27 y las 13:35, hora del Pacífico, del 29 de octubre. La compañía calcula que alcanzaron a hasta 5.000 usuarios.

El detalle que importa: no era una extensión falsa con otro nombre. Se distribuía bajo el identificador legítimo de Anthropic (anthropic.claude-code), según The Hacker News. El atacante no engañó al usuario con un nombre parecido: usó el canal oficial.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Anthropic fue tajante: sus sistemas no fueron comprometidos y el código no lo desarrolló la empresa. Felix Rieseberg, de su equipo técnico, afirmó que un actor malicioso usó el acceso a la tienda de Cursor para publicar una copia alterada. David Dworken, ingeniero de seguridad de Anthropic, añadió que no hubo compromiso de ningún sistema de Anthropic y que las versiones en sus canales oficiales no están afectadas.

Lo que sigue sin respuesta es lo más incómodo: cómo consiguió el atacante publicar bajo la cuenta de Anthropic. Ni Cursor ni Anthropic lo han explicado.

Qué hacía el código malicioso y por qué falló a medias

Según el aviso de Cursor y el análisis de Phorion, la firma que lo detectó primero en el Mac de un cliente, la extensión se activaba al arrancar el editor y hacía lo siguiente:

Añadía una clave SSH controlada por el atacante al archivo ~/.ssh/authorized_keys, etiquetada como svc-telemetry para parecer inofensiva.
Intentaba habilitar el servicio SSH local y abrir un túnel inverso hacia un servidor del atacante.
Instalaba persistencia por plataforma: una tarea programada en Windows, un crontab o un LaunchAgent en macOS, reintentando cada 60 segundos.
Enviaba datos del equipo por HTTP sin cifrar.

Los datos recolectados incluían la IP pública, el nombre del equipo y del usuario, el sistema operativo y la arquitectura de CPU, el directorio home, el email global de Git y los nombres de hasta 40 variables de entorno que contuvieran KEY, TOKEN, SECRET, PASS, AWS o GCP.

Ahí está el punto que muchos pasan por alto: los valores no viajaban en el primer envío, pero los nombres sí revelan qué proveedores de nube, sistemas de CI y tipos de credenciales tienes configurados. Es un mapa de tu stack.

La buena noticia: el paso más peligroso, habilitar el SSH local, requiere permisos de administrador que la extensión no tiene en la mayoría de equipos macOS y Windows, así que fallaba. La mala: la clave SSH, la persistencia y el envío de datos sí se completaban. Y desinstalar la extensión no basta, porque deja scripts que siguen corriendo por su cuenta.

Cómo saber si tu equipo está afectado

Cursor publicó una comprobación concreta. En macOS, desde la Terminal:

grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "clave encontrada" || echo "sin clave"

En Windows, la comprobación de PowerShell revisa también C:\ProgramData\ssh\administrators_authorized_keys. Si la clave aparece:

No confíes en desinstalar la extensión. Ejecuta el script de limpieza de Cursor.
Aísla el equipo y valora reconstruirlo.
Desde un dispositivo limpio, rota contraseñas, tokens, claves de API y sesiones a las que ese equipo tuviera acceso.

Los equipos de seguridad pueden buscar conexiones al endpoint del atacante en los puertos 22 y 8099.

Por qué esto es un problema de cadena de suministro, no de IA

Cursor retiró las versiones, cerró temporalmente su tienda, auditó el resto de extensiones, rotó sus claves y consiguió que el servidor del atacante se desconectara. Microsoft confirmó que la versión maliciosa nunca se publicó en su marketplace ni en npm, y la firma Socket no encontró evidencia de que llegara a Open VSX. El daño quedó contenido en Cursor.

Pero el patrón no es nuevo. Según The Hacker News, poco más de una semana antes un atacante reemplazó los binarios de cinco versiones ya publicadas del CLI oficial de OVHcloud con malware que roba secretos, subiéndolos desde la cuenta de GitHub de un contribuidor legítimo que había sido secuestrada en marzo de 2026.

El Informe de respuesta ante incidentes 2026 de Unit 42, de Palo Alto Networks, describe exactamente esta dinámica: el riesgo de cadena de suministro se amplió más allá del código vulnerable hacia el uso indebido de la conectividad de confianza. El mismo informe señala que las debilidades de identidad aparecieron en casi el 90% de las investigaciones y que más del 60% de las vulnerabilidades en aplicaciones nativas de la nube viven en librerías transitivas.

Qué significa esto para tu startup

Una extensión tiene los mismos permisos que tu editor y tu usuario. Si tu equipo instala herramientas desde tiendas de terceros, cada extensión es una dependencia de confianza con acceso a tu código fuente, tus archivos locales y tus credenciales de nube. Eso no se arregla con un antivirus: se arregla decidiendo qué canales autorizas.

Acciones concretas que puedes implementar esta semana:

Define una lista blanca de canales de distribución. Instala asistentes de IA y extensiones solo desde el marketplace oficial del fabricante o desde su repositorio verificado. Documenta la lista y revísala en la incorporación de cada developer.
Desactiva la actualización automática en las herramientas que tocan tu código. En Cursor las extensiones se actualizan solas por defecto. Un intervalo de 11 horas fue suficiente para llegar a 5.000 usuarios. Revisar antes de actualizar cuesta minutos; limpiar un equipo comprometido cuesta días.
Trata los secretos como si ya estuvieran expuestos. Si tienes credenciales de AWS o GCP en variables de entorno del portátil de un developer, asume que un incidente así las alcanza. Migra a un gestor de secretos y usa credenciales de corta duración.
Ten un procedimiento de rotación escrito. La pregunta no es si lo necesitas, sino si puedes ejecutarlo en una hora un viernes por la tarde.

Conclusión

El episodio no fue un fallo de Claude Code: fue un fallo del intermediario. Da igual lo seguro que sea un modelo en su canal oficial si el usuario lo instala desde la tienda de otro editor y esa tienda se ve comprometida. El eslabón débil fue la cadena de distribución, y la actualización automática convirtió un incidente de 11 horas en 5.000 posibles víctimas.

Para Cursor queda la pregunta que de verdad decide si esto puede repetirse: cómo entró el atacante en su tienda. Mientras no haya una respuesta pública, la única defensa que controlas es de dónde instalas.