Clonar i obrir un repositori a Cursor pot executar codi arbitrari a l'equip del desenvolupador abans d'escriure cap línia o llançar cap prompt a la IA. El fallo no és al model de llenguatge, sinó a l'arquitectura heretada de VS Code: tasques definides a tasks.json, extensions recomanades i configuracions de servidors MCP es carreguen automàticament en obrir la carpeta. Cursor no sempre exigeix la confirmació de Workspace Trust que VS Code imposa per defecte des de 2020. A Windows, el procés fill que executa el codi maliciós neix d'un binari signat (cursor.exe), cosa que redueix les alertes d'antivirus i EDR tradicionals.
Què passa tècnicament en obrir un repositori clonat a Cursor
Un repositori pot incloure un fitxer .vscode/tasks.json amb runOptions.runOn establert a folderOpen. Si la carpeta ja és de confiança o Workspace Trust està desactivat, la tasca s'executa sense cap confirmació addicional. No cal phishing dirigit ni que el desenvolupador interactuï amb el xat d'IA: el vector és l'acte mateix d'obrir la carpeta.
MCP: la porta del darrere amb nom propi (MCPoison i CurXecute)
El Model Context Protocol afegeix una segona superfície d'atac. El 2025, Check Point Research va documentar MCPoison: un atacant modifica silenciosament el comando d'un servidor MCP ja aprovat i, en reobrir el projecte, s'executa sense tornar a preguntar. Aim Security va descriure el mateix any CurXecute, on una resposta manipulada d'una eina MCP feia que el propi agent d'IA escrivís a la seva configuració, encadenant injecció de prompt amb execució de codi.
Per què això no és 'només' un problema de prompt injection
El punt d'entrada és l'editor actuant com a intèrpret de configuració de carpeta, no el model d'IA. Les polítiques centrades només en què pot veure o fer la IA deixen sense cobrir el vector més directe: l'execució de codi natiu disparada per obrir una carpeta.
- El desenvolupador clona i obre qualsevol repo sense revisió prèvia, amb Workspace Trust desactivat.
- Els repositoris no verificats s'obren primer en una màquina aïllada o sandbox WSL, sense credencials corporatives ni accés a la xarxa interna.
La veritat incòmoda: prohibir Cursor no és la resposta
A Blurtek no recomanem bloquejar Cursor com a primera mesura: el guany de productivitat és real, i renunciar-hi obre la porta al pitjor escenari -que els desenvolupadors l'usin igualment des del seu equip personal, sense cap control corporatiu.
Checklist: què ha de comprovar la teva empresa abans de donar Cursor als desenvolupadors
- Confirmar que Workspace Trust està actiu i no confia per defecte en carpetes noves.
- Desactivar o auditar l'execució automàtica de tasques (runOn: folderOpen) a nivell de política.
- Revisar manualment tasks.json, launch.json i mcp.json abans d'obrir repositoris externs.
- Restringir quins servidors MCP pot registrar un desenvolupador i bloquejar l'auto-aprovació de canvis posteriors.
- Clonar i obrir per primera vegada repos externs en una VM o WSL sense credencials corporatives.
- Aplicar mínim privilegi: sense permisos d'administrador local per defecte.
- Afegir regles d'EDR que alertin quan cursor.exe llanci processos fill inusuals.
Configuració mínima recomanada a Windows
- Política de grup o MDM que impedeixi desactivar Workspace Trust a nivell d'usuari.
- Compte de desenvolupament sense privilegis d'administrador local.
- Carpeta de treball per a repos externs separada de l'entorn amb credencials de producció.
- Registre centralitzat de processos fill de cursor.exe via Sysmon o l'EDR corporatiu.
Què fer si Cursor ja està desplegat sense aquests controls
El primer pas és fer un inventari real de quins equips el tenen i amb quins privilegis. A partir d'aquí, prioritza tancar el privilegi d'administrador local i activa Workspace Trust de forma centralitzada abans de tocar res més.
Si la teva empresa avalua o ja fa servir Cursor, Windsurf o un altre IDE amb IA, a Blurtek auditem la configuració real dels equips de desenvolupament i tanquem les bretxes abans que algú les trobi.
Solicitar diagnóstico