Claude Code: extensión en Cursor hackeada 11 horas

¿Qué pasó con la extensión de Claude Code en Cursor?

Una versión manipulada de la extensión oficial de Claude Code para VS Code estuvo publicada en el marketplace de Cursor durante aproximadamente 11 horas y fue descargada por «como máximo 5.000 usuarios«, según el reporte de Ars Technica. Para cualquier equipo que programa con agentes de IA, la cifra no es anecdótica: es la puerta de entrada a un backdoor con acceso a código fuente y credenciales de nube.

El aviso de seguridad de Cursor, citado por BankInfoSecurity, precisa que la versión maliciosa, la 2.1.313, estuvo disponible el jueves entre las 9:27 y las 20:35 UTC. Anthropic publicó horas después la 2.1.314, ya limpia. Lo que sigue sin respuesta es lo más incómodo: ni Cursor ni Anthropic explicaron hasta ahora cómo los atacantes obtuvieron control del canal de distribución oficial.

No fue un error de tipeo ni un paquete con nombre parecido. La versión maliciosa se publicó desde la cuenta oficial de Anthropic en el marketplace de Cursor y reemplazó a la 2.1.312, como reportaron el investigador independiente Kevin Beaumont y Luke Roberts, CTO y cofundador de la firma de detección Phorion. Como las extensiones se autoactualizan por defecto en Cursor, miles de máquinas pudieron recibir el código sin que nadie hiciera clic en nada.

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 →

¿Cómo funcionaba el backdoor y qué buscaban los atacantes?

Según el análisis del investigador Paul McCarty, difundido en el sitio OpenSource Malware y recogido por BankInfoSecurity, la extensión maliciosa era idéntica a la legítima salvo por el archivo extension.js. Ahí se insertaron 66 líneas de código antes del código real, que se ejecutan apenas arranca la extensión: no hacía falta que el desarrollador abriera a Claude.

El implante hacía cuatro cosas concretas:

Agregaba una clave SSH controlada por el atacante al archivo authorized_keys, habilitaba el servicio SSH local y abría un túnel SSH inverso hacia la dirección 134.209.82.225, que funciona incluso detrás de firewall o NAT.
Instalaba persistencia específica para cada sistema operativo (Windows, macOS y Linux) y enviaba reconocimiento del host vía HTTP sin cifrar.
Recolectaba hostname, usuario local, sistema operativo, arquitectura de CPU, directorio actual y el email global de Git asociado a los commits.
Buscaba «nombres de hasta 40 variables de entorno que contuvieran KEY, TOKEN, SECRET, PASS, AWS o GCP».

Cursor aclaró en su alerta que, por errores en el propio código malicioso, el paso de habilitar el servicio SSH fallaría salvo en circunstancias muy inusuales (por ejemplo, si Cursor se inició con privilegios de administrador). Pero eso no significa que los sistemas estén limpios: la clave del atacante igual quedó agregada, la persistencia instalada y los datos del host enviados. La recomendación es remediar todos los equipos afectados.

La compañía bajó el marketplace mientras investigaba, trabajó con el proveedor de nube para dar de baja el servidor atacante, revisó el resto de las extensiones publicadas y lo reinstaló. Beaumont advirtió además, en Mastodon, que la actualización automática a la versión limpia no borra los backdoors ya instalados: la remediación es manual, máquina por máquina.

Del lado de Anthropic, Felix Rieseberg (staff técnico) y David Dworken (seguridad) afirmaron en X, según Wired, que no hubo compromiso de sistemas ni de notebooks de empleados de la compañía, y que la extensión afectada no fue construida, publicada ni alojada por ellos. Cursor dijo lo mismo: la versión maliciosa no la desarrolló Anthropic. El eslabón que queda sin explicar es el acceso al marketplace.

Un patrón que se repite en toda la cadena de suministro de IA

Este incidente no ocurre en el vacío. El 21 de octubre, LiteLLM sufrió su segundo ataque a la cadena de suministro del año: su pipeline de releases quedó comprometido y la versión 1.107.0 se publicó en PyPI y Docker con malware que roba credenciales de nube, secretos de desarrolladores y claves de API de servicios de IA, según Help Net Security. Socket estimó las descargas semanales de LiteLLM en unos 23 millones. En el ataque anterior, de marzo, un archivo de 153 GB quedó vinculado por Hudson Rock a 2.488 dominios corporativos, incluidos AWS, Samsung, Cisco y Salesforce.

El detalle que debería inquietar a cualquier equipo de producto: según Wiz, el atacante de LiteLLM empezó a validar credenciales de AWS robadas unas 4,5 horas después de que salieran de los sistemas de las víctimas, un patrón conocido como LLMjacking. Y el stealer buscaba específicamente archivos de autenticación de Codex, Claude, Gemini y Cursor.

El vector tampoco es siempre un humano engañado. Una investigación de Bloom Security, publicada por Hackernoon, encontró más de 1.500 paquetes de npm con más de 10 millones de descargas expuestos a un secuestro de confianza: al reclamar la dirección de un repositorio renombrado o borrado, un atacante podía heredar el permiso de publicación del paquete legítimo, sin robar una sola credencial. Y en paralelo, The Hacker News documentó la campaña MALFEX, que publica paquetes maliciosos en npm desde 2023 con loaders que se activan al cargar la dependencia.

¿Por qué los agentes de IA multiplican el riesgo?

Cuando el que instala dependencias es un agente, se cae el último control humano que quedaba en la cadena. La misma investigación de Bloom Security midió que el endpoint promedio recibe alrededor de 70 paquetes instalados por agentes por mes, y que en máquinas de desarrolladores la cifra puede acercarse a 350 instalaciones mensuales.

Sumado a esto, la superficie de riesgo de un equipo de producto ya no son solo las librerías del package.json. Son extensiones del IDE, plugins del asistente, servidores MCP y agentes de terminal —todos corriendo con permisos amplios y actualizándose solos. En el caso de Cursor, la extensión corre con los permisos del IDE, así que un backdoor ahí tiene acceso inmediato a archivos locales, código fuente y herramientas de desarrollo, como explicó Phorion.

¿Qué significa esto para tu startup?

Si tu equipo usa Cursor o cualquier IDE con extensiones que se autoactualizan, el riesgo no es teórico. Estas son las acciones que puedes ejecutar esta semana:

Audita y remedia ya. Revisa en los equipos de desarrollo si la extensión de Claude Code pasó por la versión 2.1.313, busca claves SSH desconocidas en authorized_keys, conexiones salientes hacia direcciones no reconocidas y entradas de persistencia en el sistema. Cursor publicó instrucciones para detectar indicios de compromiso.
Rota credenciales, no solo actualices. Si un equipo estuvo expuesto, trata como comprometidas las claves de AWS, GCP y Azure, los tokens personales de GitHub y las API keys de proveedores de modelos que vivan en esa máquina. La lección de LiteLLM es explícita: los atacantes prueban las llaves robadas en horas, no en semanas.
Apaga el auto-update de extensiones en los equipos con acceso a producción. Fija versiones, define quién puede instalar y revisa que el publisher de la extensión sea el esperado antes de aprobar un cambio.
Saca las credenciales de producción de las laptops. Usa roles temporales con expiración, SSO y un gestor de secretos. Si el entorno de desarrollo no tiene permisos de producción, un backdoor en el IDE se vuelve un incidente contenido en lugar de una brecha.
Escribe el plan de respuesta antes del incidente. Inventario de extensiones y paquetes, criterio de aislamiento de una máquina, quién decide el forense y cómo se comunica al equipo. Improvisar esto a las 20:00 de un jueves cuesta horas críticas.

Conclusión

El ataque a la extensión de Claude Code en Cursor se resolvió con una suerte incómoda: un error en el propio malware evitó que la mayoría de los equipos quedara completamente comprometida. Ese no es un control de seguridad, es azar. La cadena de suministro del desarrollo asistido por IA —extensiones, paquetes, agentes que instalan solos— se está convirtiendo en el vector más rentable para un atacante, y las cifras de LiteLLM, de los 1.500 paquetes de npm expuestos y de las 11 horas de exposición en Cursor apuntan en la misma dirección. La defensa razonable ya no es confiar en el canal oficial, sino asumir que puede comprometerse y diseñar tu stack para que eso no te cueste las llaves de producción.