¿Realmente fueron hackeados 5000 desarrolladores? ¿Qué impacto ha tenido hasta ahora el envenenamiento del complemento de Cursor?

Nota del autor: Este artículo explica qué significa realmente que el incidente de la extensión maliciosa de Cursor haya podido afectar a un máximo de 5000 personas. También repasa la cadena de ataque, los casos verificados, el alcance del riesgo para las claves API y los pasos para revisar tu equipo, separando lo que tiene pruebas de lo que se ha exagerado.

El 29 de octubre de 2026 apareció una versión manipulada de la extensión Claude Code en el marketplace de extensiones de Cursor. En los días siguientes empezaron a circular titulares como «5000 desarrolladores hackeados» o «filtración masiva de claves API de Claude». La realidad es otra: 5000 es el límite superior de usuarios potencialmente afectados comunicado por Cursor, no el número de intrusiones exitosas confirmadas.

Esto no pretende restar importancia al riesgo. El anuncio oficial de Cursor, el equipo de investigación de seguridad de Microsoft y empresas como Phorion y Expel han confirmado que el incidente ocurrió y que se ha observado actividad maliciosa en dispositivos de clientes. Este artículo analiza seis etapas —distribución, ejecución, escritura, posibilidad de explotación, intrusión efectiva y pérdida de datos— para explicar qué hechos están verificados y qué cifras aún no se han hecho públicas.

Lo que te llevarás: Al terminar, podrás evaluar el impacto real de la extensión maliciosa de Cursor en ti y en tu equipo, y seguir los pasos oficiales para revisar tus sistemas y rotar las credenciales.

Datos clave del ataque a la extensión de Cursor

Empecemos por los hechos que ya se han confirmado. La clave para entender el incidente está en delimitar su alcance: fue un ataque a la cadena de suministro de software de una herramienta de desarrollo, no una vulneración del modelo Claude ni de los sistemas internos de Anthropic.

Anthropic afirma que no desarrolló ni publicó estas compilaciones maliciosas y que el incidente no afectó a sus sistemas internos ni a los equipos de sus empleados. Hasta el 2 de noviembre, no se habían publicado conclusiones de la investigación sobre cómo obtuvo el atacante permiso para publicar compilaciones en el marketplace de Cursor.

Cronología del ataque a la extensión de Cursor

En este incidente es fácil confundir dos períodos distintos. Uno es el intervalo durante el que se podían descargar los paquetes maliciosos desde el marketplace; el otro es el momento en que el código malicioso se ejecutó en los dispositivos donde estaba instalado. Esto último puede ocurrir mucho más tarde: retirar una extensión del marketplace no significa que los dispositivos locales ya estén a salvo.

En un principio, algunos informes también señalaron que Open VSX había sido atacado. OpenSourceMalware corrigió después esa afirmación, y Socket tampoco encontró las versiones maliciosas correspondientes al revisar los registros de Open VSX. Por ahora, el único canal que se puede confirmar como afectado es Cursor Marketplace.

Cómo funciona la manipulación maliciosa de una extensión de Cursor: de un cargador de 66 líneas a un túnel SSH inverso

Según los análisis de Phorion y OpenSourceMalware, los atacantes insertaron unas 66 líneas de JavaScript malicioso al principio del archivo extension.js de una extensión legítima, antes del código normal. El cargador se activaba en cuanto se cargaba el módulo, sin que el usuario tuviera que enviar un mensaje a Claude ni autorizar ninguna tarea de programación. La interfaz y las funciones de Claude Code seguían funcionando con normalidad, y algunos errores se gestionaban de forma silenciosa, por lo que era difícil detectar el ataque.

La cadena de ataque se puede resumir en seis pasos:

1. Recopilación de información del equipo: nombre del equipo y del usuario, sistema operativo y arquitectura de la CPU, directorio personal, directorio de trabajo, correo electrónico global de Git, IP pública, entre otros datos.
2. Inserción de una clave SSH autorizada: se añadía una clave pública controlada por el atacante al archivo authorized_keys del usuario, identificada como svc-telemetry.
3. Intento de activación del servicio SSH: si el dispositivo permitía iniciar sesión por SSH, el atacante podía acceder con la clave insertada.
4. Establecimiento de un túnel SSH inverso: el dispositivo de la víctima iniciaba una conexión con el servidor del atacante (TCP 22), que luego se redirigía al servicio SSH local para sortear algunas restricciones de entrada.
5. Implementación de persistencia: en macOS y Windows se configuraba la reconexión automática tras iniciar sesión; en Linux se usaba crontab @reboot. Así, la puerta trasera podía funcionar sin depender de la extensión. Si la conexión fallaba, se volvía a intentar aproximadamente cada 60 segundos.
6. Informe del estado de ejecución: se enviaba al servidor la información del equipo y los resultados de cada paso mediante un beacon HTTP por el puerto TCP 8099.

Por qué la manipulación de la extensión de Cursor no es una inyección de indicaciones

Al ver que «Claude Code tuvo un problema», muchas personas pensarán que una indicación maliciosa manipuló el modelo. Esta vez no fue así. Se trata de un ataque típico de ejecución de código a través de una extensión: la lógica maliciosa no tiene ninguna relación con la salida del modelo. El principio sería el mismo con cualquier otro complemento de IDE manipulado. Por eso, discutir la seguridad del modelo Claude en sí no aporta nada a este caso. El problema que realmente quedó expuesto es que, cuando alguien suplanta un canal de distribución de complementos para herramientas de desarrollo, la cadena de confianza se rompe.

Dos defectos en la implementación del código malicioso

La peligrosidad del ataque se vio reducida por errores en el código. En macOS, el código malicioso consultaba el estado de Remote Login sin permisos de administrador, por lo que el sistema devolvía un error de permisos en lugar de indicar que estaba desactivado. Como el programa solo intentaba activar SSH cuando detectaba explícitamente que estaba desactivado, este paso fallaba en muchas Mac que no lo tenían activado. En Windows, al instalar OpenSSH Server, llamaba por error a /bin/sh, una ruta de estilo Unix que no existe en un entorno estándar de Windows.

Sin embargo, los defectos no significan que el ataque fuera inofensivo. El código malicioso seguía pudiendo escribir la clave pública, generar scripts de persistencia, iniciar conexiones de red y enviar información del equipo. El riesgo era mucho mayor para los dispositivos que ya tenían SSH activado. Calum Hall, cofundador de Phorion, también señaló en una entrevista con WIRED que, de haberse implementado correctamente, esta podría haber sido una vía de acceso muy peligrosa.

¿Hackearon a 5000 desarrolladores? Los 6 niveles de impacto del ataque al complemento de Cursor

La cifra de «5000» procede de la primera versión del comunicado de Cursor, publicado el 29 de octubre: «At most 5,000 users were affected», es decir, como máximo 5000 usuarios se vieron afectados. Es el límite superior comunicado por la propia empresa, no un número de intrusiones confirmado de forma independiente por una entidad de seguridad. El comunicado inicial solo mencionaba la versión 2.1.313; la actualización añadió la 2.1.312. Sin embargo, Cursor no ha publicado cuántos usuarios corresponden a cada versión ni un desglose completo de la cifra revisada.

Si dividimos el impacto en seis niveles, resulta más fácil distinguir lo confirmado de lo que sigue siendo una hipótesis:

La diferencia entre ambos lados del gráfico es la que hay entre los titulares y la evidencia. Cuanto más descendemos en el embudo, menos evidencia pública encontramos. Por ahora, no hay pruebas que respalden afirmaciones como «5000 computadoras quedaron bajo control total» o «robaron las claves API de 5000 personas».

Qué revelan los 4 casos reales de Expel

Entre el 29 y el 30 de octubre, Expel gestionó 4 incidentes relacionados en 4 clientes, cada uno con una Mac afectada. Tres de las Mac usaban CrowdStrike Falcon y una usaba Microsoft Defender for Endpoint. En los 4 incidentes se detectaron conexiones de red con la dirección IP del servidor del atacante. Esto indica que el incidente ya había pasado de la fase de análisis del código en laboratorio a sistemas reales.

El caso más llamativo fue el de ejecución diferida. El 30 de octubre, a las 12:44, hora de Pekín, un usuario inició sesión en su Mac y abrió Cursor. Un minuto después apareció actividad maliciosa y, a las 22:29, seguían registrándose conexiones con la IP del atacante: casi 10 horas en total. Para entonces, el paquete malicioso ya llevaba tiempo retirado del marketplace. Una explicación razonable es que el paquete de instalación se descargó durante el período de exposición y se activó cuando el usuario volvió a abrir Cursor.

Estos datos tienen límites claros: 4 incidentes no significan que solo 4 dispositivos se hayan visto afectados en todo el mundo; tampoco se puede dividir 4 entre 5000 para calcular una tasa de infección. Además, detectar un túnel SSH no equivale a confirmar que el atacante haya iniciado sesión correctamente. Phorion también encontró muestras en Mac de clientes, pero no está claro si esos casos coinciden con los de Expel, así que no se pueden sumar sin más. Expel también encontró una máquina con un proceso de túnel malicioso, pero sin el marcador de clave pública svc-telemetry: buscar un solo marcador puede hacer que se pasen casos por alto.

Límites del riesgo para las claves API en el ataque a la extensión de Cursor

El código malicioso filtra hasta 40 variables de entorno cuyos nombres contienen KEY, TOKEN, SECRET, PASS, AWS o GCP. Por ejemplo, si la máquina tiene configurada OPENAI_API_KEY, el atacante puede saber que utiliza ese servicio. Sin embargo, los investigadores confirmaron que el informe inicial solo incluía los nombres de las variables, no sus valores.

Por tanto, lo preciso es decir que el código de ataque puede identificar categorías de configuraciones sensibles. Si la puerta trasera llegara a explotarse, el atacante podría acceder después a credenciales locales y código fuente. En cuanto al número de claves API realmente robadas, por ahora no hay datos públicos. Afirmar que «se robaron las claves API de todos los usuarios» equivale a confundir una capacidad con un resultado. Aun así, la incertidumbre sobre el alcance del riesgo es precisamente una razón para rotar las credenciales como medida preventiva.

Análisis del impacto del ataque a la extensión de Cursor

Impacto en los desarrolladores

• Desinstalar la extensión no basta: el equipo oficial advierte que desinstalarla o actualizarla a la versión 2.1.314 no garantiza que se eliminen las claves públicas SSH, los elementos de inicio y los scripts en segundo plano que ya se hayan instalado.
• El ataque aún puede activarse tras la retirada: el caso de activación tardía documentado por Expel muestra que quienes abrieron Cursor después de la retirada también deben revisar sus equipos.
• Las máquinas con SSH siempre activo corren más riesgo: en los equipos de desarrollo es habitual mantener Remote Login activo para la depuración remota, lo que evita precisamente el fallo de implementación del código malicioso.
• Los atacantes pueden haber identificado credenciales sensibles: aunque la puerta trasera no se haya explotado con éxito, los atacantes podrían saber ya qué servicios en la nube y API utilizas.

Impacto en los equipos y el sector

• La distribución de extensiones se convierte en una nueva superficie de ataque: las versiones de una misma extensión pueden proceder de fuentes distintas según el marketplace. Para evaluarlas, hay que tener en cuenta el origen de la instalación y los hashes de los archivos, no solo el número de versión.
• Es necesario reevaluar los permisos que reciben las herramientas de programación con IA en los equipos: las extensiones de los IDE suelen ejecutarse con permisos de usuario, pueden leer y escribir en el directorio personal y establecer conexiones de red. Las empresas deberían incluirlas en la gestión de sus dispositivos.
• La respuesta al incidente debe cubrir el ciclo de vida de las credenciales: hay que evaluar los repositorios, las claves API, las credenciales de la nube y los tokens de sesión a los que podían acceder los dispositivos afectados. Cuanto más dispersas estén las claves utilizadas por los proyectos, mayor será el costo de rotarlas.

Cómo detectar una extensión de Cursor comprometida y rotar credenciales

Primero, recomendamos usar los scripts oficiales de comprobación y reparación para macOS y Windows incluidos en el anuncio de Cursor. Los indicadores y comandos siguientes ayudan a entender e investigar el incidente, pero no sustituyen los scripts oficiales ni el análisis de registros.

Paso 1: comprobación rápida del equipo local (ejemplo en macOS)

# 1. 检查授权公钥中是否有攻击者标记（注意：没找到不代表安全，可能漏报）
grep -n "svc-telemetry" ~/.ssh/authorized_keys

# 2. 检查持久化文件与启动项
ls -la ~/.config/.smt ~/.config/.smtk ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null

# 3. 检查是否存在与恶意服务器的连接
lsof -nP -i | grep "134.209.82.225"

# 4. 确认 Remote Login 状态（需要管理员权限）
sudo systemsetup -getremotelogin

En Windows, puedes usar schtasks /query /tn SysMon para comprobar la tarea programada y buscar sysmon.cmd en la carpeta de inicio. Si encuentras cualquiera de estos indicios, conserva las pruebas, aísla el dispositivo y límpialo siguiendo los scripts oficiales. Si no puedes recuperar la confianza en el dispositivo, considera reinstalar el sistema y rotar las credenciales desde otro dispositivo de confianza.

Paso 2: identificar los nombres de las variables de credenciales expuestas

El siguiente script filtra las variables de entorno con las mismas palabras clave que el código malicioso. Solo imprime los nombres, no los valores, para ayudarte a elaborar una lista de las credenciales que debes rotar. Una vez que las hayas rotado, haz una llamada sencilla a la API para comprobar que la nueva clave funciona:

import os, re, openai

# 与恶意代码相同的关键词，列出可能被“摸底”的变量名
pattern = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")
print([k for k in os.environ if pattern.search(k.upper())])

# 在可信设备上轮换后，用新 Key 验证调用
client = openai.OpenAI(
    api_key=os.environ["NEW_API_KEY"],
    base_url="https://api.apiyi.com/v1"  # APIYI OpenAI 兼容接口
)
r = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "ping"}]
)
print(r.choices[0].message.content)

import os
import re
import openai
from typing import List

KEYWORDS = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")

def list_sensitive_env_names(limit: int = 40) -> List[str]:
    """只返回疑似凭证的环境变量名称，绝不输出值。
    limit 与恶意代码的筛选上限保持一致，用于还原攻击者可能看到的视图。"""
    names = [k for k in os.environ if KEYWORDS.search(k.upper())]
    return sorted(names)[:limit]

def verify_new_key(model: str = "gpt-4o-mini") -> bool:
    """轮换后验证新 Key 是否可正常调用"""
    client = openai.OpenAI(
        api_key=os.environ.get("NEW_API_KEY", ""),
        base_url="https://api.apiyi.com/v1"
    )
    try:
        resp = client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": "ping"}],
            max_tokens=10
        )
        return bool(resp.choices[0].message.content)
    except Exception as e:
        print(f"验证失败: {e}")
        return False

if __name__ == "__main__":
    print("可能暴露给攻击者的变量名：")
    for name in list_sensitive_env_names():
        print("  -", name)
    print("新 Key 验证结果：", verify_new_key())

Tercer paso: rota las credenciales por orden de prioridad

🎯 Consejo técnico: Si tu proyecto se conecta directamente a varias plataformas, como OpenAI, Claude y Gemini, después de un incidente tendrás que entrar en cada panel para revocar y crear nuevas claves. La recomendación oficial es centralizar la invocación de modelos en APIYI apiyi.com: una sola clave da acceso a modelos populares de varios proveedores y la interfaz es compatible con OpenAI. Así, para rotar la clave solo tienes que cambiar una configuración, y también puedes consultar el uso de forma centralizada y detectar consumos anómalos.

Preguntas frecuentes (FAQ)

Puntos clave sobre la manipulación de la extensión de Cursor

• Naturaleza del incidente: el marketplace de Cursor distribuyó una extensión manipulada. Se trata de un ataque a la cadena de suministro, no de una vulnerabilidad del modelo Claude.
• Qué significa la cifra de 5000: es el límite máximo de usuarios potencialmente afectados indicado oficialmente, no el número de intrusiones confirmadas.
• Lo que se ha confirmado: una entidad independiente observó actividad maliciosa y conexiones salientes en un Mac real.
• Lo que no se ha publicado: el número de accesos remotos exitosos, la cantidad de claves robadas y las pérdidas económicas.
• Riesgo principal: la extensión todavía podría activarse después de su retirada del marketplace, y desinstalarla no garantiza la eliminación de la puerta trasera.
• Cómo actuar: ejecuta el script oficial, rota las credenciales desde un dispositivo de confianza y usa APIYI apiyi.com para reducir el número de claves.

Resumen

Estos son los puntos esenciales del incidente de la extensión de Cursor:

1. Distingue entre titulares y pruebas: hay una gran diferencia entre «hasta 5000 personas afectadas» y «5000 personas hackeadas». Las pruebas públicas actuales confirman que el código malicioso se ejecutó en casos reales.
2. El ataque existió, pero su eficacia fue limitada: el código malicioso podía instalar una puerta trasera y mantener la persistencia, aunque los fallos de implementación en macOS y Windows redujeron la tasa de éxito de los accesos remotos.
3. No basta con una sola comprobación: revisa el origen de la instalación, los hashes de los archivos, los procesos, las conexiones de red y los elementos de inicio. Buscar solo svc-telemetry podría dejar amenazas sin detectar.

Si usaste la extensión Claude Code desde el marketplace de Cursor entre el 29 y el 30 de octubre, sigue primero las instrucciones oficiales para comprobar tu equipo y después rota las credenciales por orden de prioridad. En cuanto a las API de modelos, puedes aprovechar para centralizar las claves dispersas en APIYI apiyi.com: la próxima vez que necesites rotarlas de emergencia, será mucho más sencillo.

📚 Referencias

1. Aviso oficial de seguridad de Cursor: cronología del incidente, versiones, hashes de archivos maliciosos y scripts de limpieza
2. Enlace: cursor.com/blog/claude-code-extension-security-notice

3. Nota: es el primer recurso que conviene consultar para revisar tu sistema; incluye scripts de reparación para macOS y Windows

4. Microsoft Security Research: análisis de la cadena de ataque de la extensión maliciosa de Claude Code

5. Enlace: microsoft.com/en-us/security/blog/2026/10/30/inside-malicious-claude-code-branded-cursor-extension-persistent-ssh-backdoor/

6. Nota: permite verificar los límites de la cadena de suministro, el mecanismo SSH y los detalles de persistencia

7. Phorion: Official Claude Code Extension Compromise

8. Enlace: phorion.io/blog/offical-claude-code-vsx-compromise/

9. Nota: detalles técnicos del cargador de 66 líneas, las diferencias entre plataformas y los defectos del código

10. Expel: Fake Claude Code extensions in Cursor

11. Enlace: expel.com/blog/blog-fake-claude-code-extension-cursor-ssh-backdoor/

12. Nota: cuatro incidentes reales de clientes y casos de ejecución diferida

13. Socket: Cursor Removes Malicious Claude Code Extension

14. Enlace: socket.dev/blog/claude-code-extension-compromise
15. Nota: verificación de los registros de Open VSX y npm, con correcciones de informes iniciales erróneos

Autor: Equipo técnico de APIYI
Intercambio técnico: puedes contactarnos a través de la página principal de APIYI, apiyi.com. Encontrarás más recursos de integración en el centro de documentación docs.apiyi.com

Artículos relacionados

• Extensión de Claude Code comprometida: puerta trasera en la versión 2.1.313 y 5 pasos para detectarla y eliminarla: El 29 de octubre, las versiones 2.1.312 y 2.1.313 de Claude Code en Cursor Marketplace incluyeron una puerta trasera SSH que expuso hasta 5.000 usuarios; en 5 pasos, revisa la clave pública svc-telemetry, elimina LaunchAgent y tareas programadas, actualiza a 2.1.314+ y rota las credenciales de GitHub, la nube y APIYI.
• Claude Max cambia su nombre a Ultra: ¿se eliminó el límite de 5 horas? Conoce primero los 3 cambios: Claude Max 20x pasa a llamarse Ultra y Max 5x pasa a llamarse Max, sin cambios de precio; las cuentas Ultra verificadas ya no tienen límite de 5 horas, pero mantienen el semanal, y este artículo te ayuda a decidir si cambiar de plan mediante una tabla comparativa, 3 pasos de revisión y cálculos.