Cursor IDE bajo ataque: dos fallas zero-click permiten RCE fuera del sandbox (CVE-2026-50548 / CVE-2026-50549)

Contexto del incidente

El 1 de julio de 2026 el equipo de Cato AI Labs divulgó públicamente DuneSlide, una cadena de dos vulnerabilidades críticas en Cursor, el editor de código con IA que según el propio fabricante ya adoptaron más de la mitad de las compañías Fortune 500. Registradas como CVE-2026-50548 (CWE-22, path traversal vía parámetro working_directory) y CVE-2026-50549 (CWE-59, fallo en la canonicalización de symlinks), ambas comparten vector CVSS 4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N y un puntaje de 9.3 CRITICAL asignado por el CNA de GitHub (NVD). Algunas mediciones paralelas — incluyendo las del propio equipo de Cato y la cobertura de SecurityWeek, The Hacker News y Daily Security Review — citan 9.8 sobre la base CVSS 3.1; las dos cifras son consistentes porque corresponden a las dos versiones del estándar y no a una discrepancia.

Lo que vuelve a DuneSlide particularmente grave no es el puntaje, sino el mecanismo de entrega. Cursor 2.x ejecuta comandos del agente dentro de un sandbox local de forma automática, justamente para evitar la fatiga de aprobar cada npm install o cada test run. Ese sandbox construye su allowlist de directorios escribibles a partir del parámetro working_directory que el propio LLM decide en cada invocación de la herramienta run_terminal_cmd. Si una inyección de prompt — originada en una respuesta de un servidor MCP malicioso, una página web que el agente lee con su herramienta de búsqueda, o un README en un repositorio público que el developer abre — logra que el LLM asigne un working_directory fuera del proyecto, ese path externo se suma ciegamente a la lista de directorios escribibles del sandbox. Un paso después, el atacante sobrescribe el binario cursorsandbox que aplica el sandboxing, y todos los comandos subsiguientes del agente corren sin ninguna restricción, ya con permisos plenos del usuario que abrió Cursor.

La segunda vulnerabilidad, CVE-2026-50549, es un espejo funcional de la primera: explota la lógica de canonicalización de paths cuando Cursor resuelve symlinks antes de escribir un archivo. Si la canonicalización falla — porque el target no existe o porque el agente le removió permisos de lectura a un directorio padre — Cursor vuelve al path original del symlink y escribe ahí, sin validar que ese path sigue dentro del workspace. Eso permite que un symlink creado dentro del proyecto apunte hacia afuera (a ~/.zshrc, ~/Library/LaunchAgents, al propio helper de sandbox, etc.) y termine escribiendo archivos arbitrarios bajo los privilegios del developer.

La seguridad de un agente de IA no se rompe en el modelo: se rompe en el límite entre el LLM y el sistema operativo. Cursor aprende esa lección dos veces en el mismo advisory, y los equipos azules tenemos que asumir que la próxima IA editora tendrá un tercer cuelo de botella diferente.

El detalle operacional más incómodo para los blue teams es la ventana silenciosa de tres meses. Cursor ya tenía el parche disponible desde el 2 de abril de 2026 en la versión 3.0, pero los CVE IDs se asignaron recién el 5 de junio y la divulgación pública con detalles técnicos ocurrió el 1 de julio. Durante todo ese trimestre, cualquier organización con Cursor < 3.0 instalado corría software vulnerable sin tener forma pública de saberlo: el catálogo de NVD todavía no tenía la entrada, ni los advisories del vendor estaban publicados. Cursor rechazó el reporte original de Cato el 23 de febrero con el argumento de que el abuso de servidores MCP "no entraba en su threat model"; sólo reabrió el caso tras la escalada del 26 de febrero y terminó incluyendo ambos fixes en 3.0. Esa secuencia importa porque va a repetirse con cada nuevo AI editor mientras la industria no resuelva qué hacer con el modelo de threat del LLM-as-tool-user.

¿Cómo proteger tu infraestructura?

1. Confirmá la versión de Cursor y forzá 3.0+ desde tu MDM

La acción inmediata es cerrar la ventana silenciosa. En macOS: Cursor → About Cursor; en Windows y Linux: Help → About. Si la versión es 2.x o anterior, actualizá ahora — Cursor 3.0 está disponible desde el 2 de abril y contiene los dos fixes. Para organizaciones con cientos de developers, el camino correcto es empujar la versión mínima vía MDM (Jamf, Intune, Kandji o Fleet) y bloquear el downgrade: Cursor no se autoupdate agresivamente en Linux, así que ese vector queda completamente en manos del equipo de IT. Donde no se pueda actualizar por incompatibilidades con extensiones críticas, el workaround es deshabilitar el Background Agent y cualquier servidor MCP declarado en ~/.cursor/mcp.json hasta poder migrar.

2. Sacá Cursor de la laptop: devcontainers, Codespaces o Docker sin privilegios

DuneSlide demuestra que ningún sandbox interno al editor es suficiente cuando el LLM mismo controla qué escribir. La defensa en profundidad correcta es aislar Cursor en un entorno desechable. Devcontainers de VS Code, GitHub Codespaces, Gitpod, o un container con docker-in-docker ejecutado como usuario sin privilegios: si el agente queda comprometido, la RCE muere con el contenedor y las credenciales del developer, sus SSH keys y sus tokens de GitHub o AWS nunca salen del host físico. Es el equivalente moderno de "no navegar producción desde la misma máquina donde se lee email", pero aplicado al lugar donde hoy se ejecuta el 80% del código nuevo. Cursor corre sin problemas dentro de devcontainers estándar con Debian/Ubuntu base.

3. Auditoría de servidores MCP y principio de menor privilegio

El vector de entrada real de DuneSlide fueron servidores MCP maliciosos (o legítimos pero comprometidos) que el agente llamó durante operaciones rutinarias. Cada .cursor/mcp.json declarado en un proyecto es un supply chain attack surface que tenés que tratar como si fuera una dependencia de npm: whitelist explícita de servidores permitidos, rechazo por default de cualquier server no firmado por el equipo de plataforma, permisos read-only por defecto y sólo escalar a write cuando la tarea específica lo justifique. Si tu equipo usa el MCP oficial de Linear, recordá que fue literalmente el caso que Cursor rechazó como "fuera de scope" en febrero: sí, está dentro del scope de riesgo operacional.

4. Monitoreo de la integridad del binario cursorsandbox

Ambas CVE convergen en el mismo objetivo final: reemplazar el helper de sandbox para que los próximos comandos corran sin restricciones. Eso da un punto de detección limpio y muy poco ruidoso: monitorizá la integridad del binario /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox en macOS, %LOCALAPPDATA%\Programs\Cursor\resources\app\resources\helpers\cursorsandbox.exe en Windows, o ~/.local/share/cursor/resources/app/resources/helpers/cursorsandbox en Linux. Un hash SHA-256 conocido, alerta cuando cambie sin un update oficial, alerta cuando su mtime se modifique fuera de un upgrade del paquete. File integrity monitoring maduro como OSSEC, Wazuh o Falco cubre este caso con tres líneas de regla.

Indicadores de compromiso (IoC)

Estos son los indicadores específicos que dejó DuneSlide en una máquina comprometida. Si los cazás en tu EDR, FIM o logs de host, la laptop del developer está bajo ataque activo o ya fue breachada:

• Binario cursorsandbox modificado fuera de un upgrade: cualquier cambio en el helper de sandboxing (paths arriba según SO) cuyo mtime o SHA-256 no coincida con el publicado por Cursor para esa versión específica es compromiso confirmado. Cursor sólo toca ese binario durante un update firmado del paquete; toda otra modificación es maliciosa por definición.
• Symlinks sospechosos en el árbol del proyecto: symlinks que el agente (no el developer) haya creado apuntando fuera del workspace, especialmente hacia ~/.zshrc, ~/.zshenv, ~/.bash_profile, ~/Library/LaunchAgents, /Applications/Cursor.app/Contents/Resources/, /etc/cron.d/ o /usr/local/bin/. Detectá con find . -type l \( -lname '/Users/*' -o -lname '/Applications/*' -o -lname '/etc/*' -o -lname '/usr/*' \) corriendo desde la raíz de cada repo donde Cursor estuvo activo en las últimas 72 horas.
• Llamadas a run_terminal_cmd con working_directory anómalo: si tu organización instrumentó el audit log de Cursor (Cursor 3.x expone logs en ~/Library/Logs/Cursor/ en macOS), filtrá invocaciones donde working_directory apunte fuera del project root. Un valor legítimo siempre contiene el path absoluto del proyecto; un exploit DuneSlide típicamente pasa /Users/<victim>/.zshrc, /Library/LaunchAgents/ o /tmp/.
• Persistencia en shell rc o LaunchAgents: modificación de ~/.zshrc, ~/.zshenv o ~/.bash_profile con líneas nuevas que ejecutan binarios desde paths sospechosos (curl ... | bash, /tmp/curl*, paths bajo /var/folders/); archivos .plist nuevos en ~/Library/LaunchAgents/ que el developer no creó manualmente; entradas en /etc/cron.d/ con timestamps que no coinciden con deploys de sistema.
• Procesos hijos de Cursor fuera del sandbox: en un host sano los procesos lanzados por el agente están envueltos en un profile de sandbox (sandbox-exec en macOS, bwrap en Linux o un perfil AppArmor). Cualquier bash, sh, python, curl, nc o wget que aparezca como hijo de Cursor sin ese wrapper es compromiso probable — auditable vía ps -ef --forest | grep -A5 Cursor filtrando por PPID del proceso principal.
• Conexiones outbound desde Cursor hacia destinos no documentados: Cursor sólo habla con Anthropic, OpenAI (cuando configuraste modelos BYOK), api.cursor.sh y los servidores MCP que vos declaraste. Tráfico HTTPS desde Cursor.app o el binario cursor hacia IPs que no están en tu allowlist de proveedores de IA — especialmente hacia puertos no estándar como 4444, 8080 o 9001 — es indicador fuerte de exfiltración o de callback post-explotación.

# Detección de symlinks implantados por DuneSlide en un repo donde Cursor estuvo activo
# Ejecutar desde la raíz del repo. Reportar todo symlink con destino fuera del workspace.
find . -type l -print | while read link; do
  target=$(readlink "$link")
  case "$target" in
    /Users/*|/Applications/*|/etc/*|/usr/local/*|/Library/LaunchAgents*|/var/folders/*|/tmp/*)
      echo "[SUSPECHA] symlink intra-repo apunta afuera: $link -> $target" ;;
  esac
done

# Verificación de integridad del binario cursorsandbox en macOS
# Cursor 3.0.x esperado: hash publicado por el vendor. Cualquier diferencia = compromiso.
SB="/Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox"
shasum -a 256 "$SB"
stat -f '%Sm  %z bytes  %N' "$SB"

# Regla Wazuh/FIM para cursorsandbox (ejemplo genérico, ajustar al syscheck del agente)
<syscheck>
  <directories check_all="yes" realtime="yes">/Applications/Cursor.app/Contents/Resources/app/resources/helpers</directories>
</syscheck>

# Regla YARA local para detectar cursorsandbox reemplazado por un script
# (heurística: archivo con shebang en lugar de binario Mach-O/ELF/PE)
rule cursorsandbox_substituted {
  meta: description = "cursorsandbox replaced by a script (DuneSlide post-exploit)"
  strings:
    $shebang = /^#!.*(sh|python|perl|ruby)/
    $bin = { 7F 45 4C 46 }    // ELF magic
    $macho = { CF FA ED FE }  // Mach-O 64 magic
  condition:
    filesize < 1MB and $shebang and not ($bin or $macho)
}