Seguridad de Cursor: riesgos, controles y buenas prácticas

¿Qué es Cursor y por qué cambia el modelo de seguridad?

Cursor es un editor de código centrado en la IA, un fork de VS Code reconstruido en torno al modelo en lugar del archivo. Funciona dentro del flujo normal del desarrollador (el editor, la terminal integrada, el panel del agente) y actúa sobre instrucciones en lenguaje natural: explica esta base de código, construye esta funcionalidad, arregla esta prueba que falla, refactoriza a través de estos archivos. Para hacerlo bien indexa el repositorio para que el modelo tenga contexto, edita varios archivos en una sola ejecución del agente, ejecuta tareas y comandos de terminal, y se extiende a través del Model Context Protocol (MCP) para alcanzar bases de datos, sistemas de seguimiento de incidencias y herramientas internas.

Esa combinación es la que rompe el viejo modelo de seguridad. Un asistente de IDE clásico ofrecía un completado; una persona lo leía y elegía aceptarlo o rechazarlo. El radio de impacto de una mala sugerencia era un bloque de código que un desarrollador todavía tenía que pegar. Cursor, en cambio, ejecuta acciones. Lee archivos que nunca nombraste, ejecuta comandos que nunca escribiste, reescribe código por todo el árbol y puede ejecutar una tarea en el momento en que abres una carpeta. La superficie de ataque ya no es "qué sugirió el modelo". Es "qué puede hacer este editor con el acceso que tiene, qué código puede generar en volumen y quién puede influir en sus instrucciones".

“

Una sugerencia es un borrador que una persona elige aceptar. Una acción es algo que ya ocurrió. El modelo de seguridad tiene que pasar de revisar borradores a restringir acciones.

Hay un segundo cambio, y tiene que ver con la velocidad. El pull request se convirtió en el hogar de la seguridad de las aplicaciones porque operaba a ritmo humano: una persona bajaba el ritmo, leía el diff y solo entonces fusionaba. Cursor no corre a ritmo humano. Una sola sesión del agente puede producir más código en una tarde del que un revisor lee en una semana, y el editor generará alegremente código funcional que es, en silencio, inseguro. Cuando eso ocurre, el diff deja de ser un punto de control y se convierte en una transcripción de decisiones ya tomadas. Cualquier control que solo actúe en el pull request ahora revisa historia, no la previene.

Para la mayoría de los equipos la pregunta práctica no es si Cursor tiene protecciones nativas. Las tiene, y varias son genuinamente buenas. La pregunta es si bastan para el uso diario. La respuesta honesta es no. La propia página de seguridad de Cursor documenta controles reales, y reducen el riesgo, pero una adopción segura sigue dependiendo de los permisos, el aislamiento, la supervisión humana y la validación independiente sobre el código, las dependencias, los secretos y los pipelines.

Cómo funciona el modelo de seguridad de Cursor

El modelo de Cursor se construye sobre tres ideas: demostrar que la plataforma maneja los datos de forma responsable, dar al desarrollador palancas para mantener el código sensible fuera del alcance del modelo, y contener lo que un proyecto abierto puede hacer. En la práctica eso se manifiesta en un puñado de controles.

Es una base razonable, y la mayor parte de esto no existía en los asistentes de IDE de hace una generación. La trampa es leerla como una frontera de seguridad terminada. Privacy Mode protege tus datos pero no dice nada sobre la seguridad del código que Cursor escribe. .cursorignore solo funciona si lo mantienes. Workspace Trust solo te protege si está activado, y durante buena parte de la historia de Cursor no lo estaba. SOC 2 atestigua cómo Cursor opera su servicio, no lo seguro que se comporta en tu máquina. Cada control de aquí tiene un borde documentado, y la siguiente sección trata de lo que ocurre cuando te apoyas en ellos en exceso.

Los 6 principales riesgos de seguridad en Cursor

Los riesgos siguientes no son teóricos. Se corresponden con vulnerabilidades divulgadas, investigación publicada y el OWASP Top 10 para Aplicaciones LLM. Las cifras que los enmarcan son las mismas que ahora cita todo equipo de AppSec.

1. Workspace Trust desactivado por defecto, que lleva a ejecución silenciosa de código

Este es el problema característico de Cursor. En septiembre de 2025, The Hacker News informó de un fallo ("Cursor AI Code Editor Flaw Enables Silent Code Execution via Malicious Repositories") arraigado en que Workspace Trust venía desactivado por defecto. Como Cursor es un fork de VS Code, un proyecto puede llevar una tarea de .vscode/tasks.json configurada con runOn: folderOpen, y con la confianza desactivada esa tarea se ejecuta en el instante en que un desarrollador abre la carpeta, corriendo código arbitrario en el contexto del usuario.

El ataque es trivial de montar. Un atacante publica un repositorio tentador en GitHub, esconde una tarea de "autorun" dentro de él y espera a que alguien lo clone y lo abra en Cursor. Sin aviso, sin clic, sin revisión: abrir el proyecto basta para filtrar credenciales, modificar archivos o plantar un punto de apoyo para un compromiso más amplio. Los investigadores (Oasis Security) recomendaron la misma mitigación que nosotros: activa Workspace Trust, abre primero los repositorios no confiables en un editor distinto y audita un proyecto antes de abrirlo en Cursor. El arreglo es un solo ajuste, pero solo ayuda a los desarrolladores que saben que hay que activarlo.

2. Código inseguro generado por IA

El trabajo de Cursor es escribir código rápido, y rápido no significa seguro. El benchmark SusVibes de Carnegie Mellon, que rastrea agentes de programación comerciales incluido Cursor, halló que la combinación de agente y modelo más fuerte producía código funcionalmente correcto el 61% de las veces, pero código seguro solo el 10.5% de las veces, y que más del 80% de las soluciones funcionalmente correctas aún arrastraban una vulnerabilidad. La brecha entre "funciona" y "es seguro" es donde vive el peligro: código que pasa la prueba y envía la vulnerabilidad.

Los patrones son predecibles. SQL concatenado con cadenas en lugar de consultas parametrizadas (la clásica inyección SQL), prototype pollution en JavaScript, codificación de salida ausente que abre XSS, validación de entradas ausente en endpoints generados. No son bugs exóticos; son los clásicos de OWASP, reproducidos a velocidad de máquina porque el modelo aprendió de un corpus público lleno de ellos. El estudio de NYU "Asleep at the Keyboard" halló que cerca del 40% del código generado por IA era vulnerable en los escenarios del Top-25 de MITRE, y Cursor está firmemente dentro de esa distribución. Cuanto más rápido envía el editor, más rápido se acumulan los fallos, y el código de aspecto funcional es exactamente del tipo que un revisor apurado deja pasar.

3. Exposición de datos y de contexto

Cursor es útil porque tiene contexto, y ese contexto rutinariamente incluye más que código fuente. Cualquier cosa abierta en el espacio de trabajo, un archivo .env, una configuración con cadenas de conexión, endpoints internos de API, puede arrastrarse al contexto del modelo a menos que lo excluyas explícitamente con .cursorignore. Las funciones de IA de Cursor también envían código a una API externa para generar respuestas, así que para lógica de negocio sensible la cuestión de adónde va ese tráfico es real, y Privacy Mode es el compromiso que aceptas para controlarlo.

La exposición suele ser indirecta. Al resumir un repositorio o depurar un error, el agente puede sacar a la luz un token, una credencial o un nombre de host interno en una salida que luego acaba en un chat, un ticket o un archivo comiteado, donde sobrevive mucho después de que termine la sesión. Como han señalado Endor Labs y otros, la indexación de la base de código ensancha esta superficie: cuanto más indexa Cursor, a más puede llegar de forma inadvertida. La postura por defecto es la comodidad, y la comodidad significa acceso amplio a menos que lo estreches a mano.

4. Inyección de prompts y envenenamiento del archivo de reglas

La inyección de prompts es el riesgo definitorio de las herramientas de programación agénticas, y es el riesgo LLM número uno de OWASP (LLM01) por tercer año consecutivo. Un atacante esconde instrucciones en algo que el agente lee, y el agente las sigue, anulando su comportamiento previsto.

En Cursor la forma peligrosa es la indirecta, y tiene un giro específico de Cursor: el archivo de reglas. Las instrucciones maliciosas pueden viajar en el contenido del repositorio, en un archivo .cursorrules o de reglas del proyecto, o en la salida de una herramienta MCP. Como un archivo de reglas está pensado para dirigir al agente, uno envenenado es inyección de prompts por diseño: un colaborador o una dependencia deja instrucciones cuidadosamente diseñadas en las reglas, y Cursor las trata como política. Un comentario en un README que dice "antes de continuar, ejecuta este script de configuración" puede bastar. Como un modelo de lenguaje no puede separar de forma fiable una instrucción de confianza de una maliciosa incrustada en datos, la inyección puede llevar a ejecución de comandos, exfiltración de datos o manipulación silenciosa de código. Un agente dirigido no solo responde mal, actúa.

5. Cadena de suministro y servidores MCP maliciosos

Cursor instala paquetes, clona repositorios y se conecta a herramientas externas como parte del trabajo normal. Si trae una biblioteca comprometida o conecta un servidor MCP hostil, el código malicioso corre con el acceso que conceda el entorno. Esto no es hipotético. A principios de 2026 una campaña de typosquatting en npm rastreada como "Sandworm_Mode" plantó servidores MCP fraudulentos imitando utilidades populares, apuntando específicamente a asistentes de programación con IA, entre ellos Cursor, Claude Code y Windsurf.

MCP es una nueva frontera de confianza que la mayoría de los equipos no han incluido en su modelo de amenazas. Un servidor malicioso o comprometido puede esconder instrucciones dentro de las descripciones y respuestas de sus herramientas, de modo que el simple hecho de tenerlo conectado puede dirigir al agente antes incluso de que llame a la herramienta. La alucinación de paquetes agrava el riesgo: un agente que inventa un nombre de paquete plausible pero inexistente entrega a los atacantes un hueco para registrarlo y convertirlo en arma. El agente a menudo aprobará la instalación con confianza, porque el nombre parece correcto y la tarea lo pedía.

6. Vulnerabilidades documentadas del editor que llevan a RCE

Más allá del fallo de autorun, Cursor ha acumulado una serie de avisos de seguridad, incluyendo investigación publicada por grupos como Geordie AI, que cubren vectores de bypass de confianza y ejecución de código en el propio editor (hooks de Git ocultos, ejecución persistente mediante bypass de confianza de MCP y problemas relacionados). El tema recurrente es que Cursor es razonablemente seguro como IDE, y notablemente inseguro como generador automatizado de código sin una capa de revisión externa.

El peligro se agrava cuando el editor corre con acceso amplio a la máquina del desarrollador. Una cadena de acciones individualmente inofensivas, instala esta dependencia, ejecuta esta tarea, aplica esta edición, puede instalar malware, alterar una configuración de CI o abrir un mecanismo de persistencia. Por eso exactamente importan el gating de confianza, el privilegio mínimo y los entornos aislados, y por eso la combinación que hay que temer es la habitual: un repo no confiable, una configuración permisiva para evitar fricción y una instrucción inyectada que el editor trata como legítima.

Qué cubre la seguridad nativa de Cursor y qué no

Los controles nativos son reales, y conviene ser preciso sobre la línea entre lo que gestionan y lo que te dejan a ti.

Lee la columna de la derecha como el trabajo real. Los controles nativos de Cursor están inclinados hacia la privacidad de datos y el cumplimiento del proveedor, que es donde aterrizan las primeras preguntas de un comprador. Nunca se diseñaron para frenar a un adversario decidido que controla las entradas del editor, y dicen casi nada sobre la seguridad del código que Cursor escribe. Todo lo que convierte "Cursor está instalado" en "Cursor está gobernado" vive en las prácticas que siguen.

Buenas prácticas para asegurar Cursor

Estas nueve prácticas cierran la brecha entre la base nativa y una postura de seguridad real. Ninguna es exótica; la disciplina está en aplicarlas de forma consistente en un equipo que se mueve rápido.

1. Activa Workspace Trust y trata los repos no confiables como hostiles. Activa Workspace Trust como parte estándar de la configuración inicial, para que una carpeta abierta no pueda autoejecutar una tarea. Abre primero los repositorios que no escribiste tú en un entorno aislado (sandbox) o en un editor distinto, audita .vscode/tasks.json y cualquier hook de Git antes de confiar en ellos, y nunca explores un tentador repo público en tu instancia principal de Cursor sin comprobar qué tiene permitido ejecutar.

2. Mantén Privacy Mode activado para el trabajo sensible y asume el compromiso. Privacy Mode es el control que evita que tu código se almacene o se use para entrenamiento. Trátalo como el valor por defecto para cualquier repositorio con lógica de negocio real, datos regulados o código propietario. Cuando un equipo elija desactivarlo para una función, que sea una decisión explícita y documentada, acotada al trabajo de baja sensibilidad, no un valor por defecto silencioso que todos olvidaron comprobar.

3. Cuida .cursorignore como un artefacto de seguridad. Excluye los archivos .env, los almacenes de credenciales, la configuración de infraestructura, las cadenas de conexión y cualquier módulo sensible tanto del contexto de la IA como de la indexación. Revisa el archivo de ignorados como revisas el control de acceso: según un calendario, después de añadir cada nuevo secreto o servicio, y como parte de la incorporación de un nuevo repo. Un .cursorignore desactualizado es la forma más común de que un secreto acabe en el contexto de un modelo.

4. Mantén a una persona en el bucle sobre el código generado. Trata la salida de Cursor como un borrador, no como una implementación terminada. Encamina todo el código generado o modificado por revisión de pull request y pruebas automatizadas, con escrutinio extra en autenticación, validación de entradas, consultas SQL y rutas con privilegios, precisamente las áreas donde los datos de SusVibes muestran que el modelo se equivoca. El objetivo no es desconfiar de la herramienta; es que un editor que produce miles de líneas al día produce fallos sutiles más rápido de lo que afloran por sí solos.

5. Analiza el código generado por IA con SAST en CI. Como solo una pequeña fracción de las soluciones de IA son seguras por defecto, un control de análisis estático no es opcional. Ejecuta SAST en cada pull request, haz que la compilación falle ante hallazgos de alta severidad (inyección SQL, XSS, prototype pollution, autorización ausente) y devuelve los resultados a los desarrolladores para que las mismas clases dejen de repetirse. Las pruebas funcionales no atraparán un endpoint vulnerable pero funcional; solo lo hará una comprobación consciente de la seguridad.

6. Gobierna dependencias, paquetes y servidores MCP. Restringe las instalaciones a registros de confianza o espejos internos, exige aprobación para paquetes nuevos y analiza todo con análisis de composición de software. Verifica cada servidor MCP como una frontera de confianza: usa los que escribiste tú o en los que confíes genuinamente, acota cada uno a los datos y acciones más estrechos que necesita, y mantén un inventario para que un paquete con typosquatting como los servidores de "Sandworm_Mode" no se cuele sin que nadie lo note.

7. Gestiona los secretos fuera de alcance. Mantén los secretos en texto plano fuera del espacio de trabajo que el agente puede ver. Usa una bóveda e inyéctalos en tiempo de ejecución, redacta los valores sensibles en los registros y en la salida, y nunca dejes archivos de credenciales donde la indexación de Cursor pueda alcanzarlos. Si un secreto aparece alguna vez en una transcripción, un archivo generado o un commit, rótalo de inmediato e investiga cómo llegó ahí.

8. Ejecuta el trabajo arriesgado en entornos aislados y de privilegio mínimo. Usa contenedores o VM en entorno aislado (sandbox) para el trabajo asistido por IA sobre código no confiable, ejecuta Cursor sin privilegios elevados y bloquea las conexiones salientes no aprobadas para que una sesión comprometida no pueda exfiltrar. Segmenta los entornos por sensibilidad para que el trabajo de alto riesgo quede contenido y el radio de impacto de cualquier compromiso individual siga siendo pequeño.

9. Fija la política por sensibilidad de repositorio y entorno. Clasifica los repositorios (público, interno, regulado, producción) y aplica controles más estrictos a los sensibles: Privacy Mode activado, indexación acotada, salida restringida, revisión más fuerte requerida. Para sistemas críticos, usa Cursor solo en entornos sin ruta directa a credenciales de producción, y documenta la política para que los desarrolladores sepan dónde se permite la ayuda de IA y bajo qué restricciones.

Donde se detienen los controles nativos: asegurar al agente en el momento del prompt

Recorre de nuevo los riesgos y emerge un patrón. Workspace Trust, Privacy Mode, .cursorignore y SAST actúan todos sobre lo que el editor ya ha decidido hacer, o sobre código que ya ha escrito. Se agrupan alrededor del pull request, porque ahí ha vivido siempre la AppSec. Pero el PR solo fue un punto de control porque una persona lo leía, y a ritmo de agente ya nadie lo lee de principio a fin.

El lugar para aplicar una regla ya no es el diff; es el prompt, antes de que se escriba la línea insegura. Cualquier regla que quieras que Cursor siga tiene que estar en sus manos en el momento en que escribe, no esperando en un escáner que llega una vez que el código está en disco y el agente ha pasado a la siguiente tarea.

Esa es la capa que añade VibeDefend. Es una CLI de npm gratuita que se instala en unos cinco segundos y conecta Cursor (además de Claude Code, OpenAI Codex, Windsurf y VS Code Copilot) en cuatro capas de gobierno que corren dentro del bucle del agente.

Reglas de negocio Las convenciones de tu repo que nunca se escribieron (usa Decimal128 para el dinero, la autorización pasa por requireOwner). VibeDefend las extrae de cómo tu equipo ya programa y las carga en el contexto de Cursor antes de cada edición. Reglas de seguridad OWASP Top 10, SOC 2, RGPD e ISO 27001, cargadas el día que instalas. El agente lee el recordatorio aplicable antes de escribir, así el requisito del marco se vuelve parte del código en lugar de una casilla a marcar en auditoría. Action Guard Las llamadas destructivas (un sudo rm -rf, una lectura cruda de una variable de entorno con forma de secreto, un psql improvisado contra un host de producción) se interceptan antes de dispararse. Advierte o bloquea según la regla, con cada intercepción en el registro de auditoría. Live Findings Cada resultado de sus escáneres de CybeDefend (SAST con alcanzabilidad, SCA, secretos, IaC y CI/CD) está en vivo en el contexto de Cursor, así que no solo escribe código seguro, también tría y arregla las vulnerabilidades que ya tienes.

Es importante destacar que nada de tu código cruza la red. Las decisiones ocurren localmente, junto al agente; solo metadatos de gobierno estructurados (la regla que se disparó, la ruta del archivo, la severidad, una marca de tiempo) llegan al backend. Los tenants de EU y US están físicamente separados, y eliges la región en el momento de la instalación. Ese modelo de privacidad es lo que permite que un control se sitúe tan cerca del código sin convertirse, por sí mismo, en un riesgo de exfiltración de datos, la misma preocupación que hace del propio Privacy Mode de Cursor un compromiso.

Esto no es un reemplazo de las prácticas anteriores. Es la capa que falta y que ellas dan por hecha: la que pone tus reglas en las manos de Cursor en el momento del prompt, para que la línea insegura se reescriba antes de siquiera sugerirse, en lugar de atraparse tres etapas después por un escáner que lee un diff que nadie tuvo tiempo de leer. Workspace Trust impide que el editor haga lo que no debe; VibeDefend moldea lo que escribe, de entrada.

Preguntas frecuentes

¿Es seguro Cursor?

Cursor es seguro de usar cuando está configurado y contenido, y arriesgado cuando no lo está. Su cumplimiento SOC 2 Type II, Privacy Mode, .cursorignore y Workspace Trust previenen una clase real de fugas de datos y accidentes. El riesgo residual viene de los valores por defecto (Workspace Trust históricamente desactivado, indexación amplia), del código que genera (solo una pequeña fracción es seguro nada más sacarlo de la caja), de las entradas (inyección de prompts, archivos de reglas envenenados, servidores MCP maliciosos) y del entorno circundante (secretos expuestos, repos no confiables). Trátalo como un agente poderoso que necesita gating de confianza, exclusión de secretos, revisión humana y SAST, no como una herramienta segura por defecto.

¿Cursor envía mi código a la nube?

Sí. Las funciones de IA de Cursor envían código a una API externa para generar respuestas, lo que puede incluir contenidos de archivos y el contexto circundante de tu tarea. Privacy Mode cambia lo que ocurre con ese código del lado de Cursor: con él activado, tu código no se almacena ni se usa para entrenar modelos. Para lógica de negocio sensible, mantén Privacy Mode activado, excluye los secretos y los datos regulados del contexto con .cursorignore, y revisa la política de manejo de datos de Cursor en cursor.com/security frente a tus propios requisitos.

¿Qué es .cursorignore y por qué importa?

.cursorignore es un archivo (similar en espíritu a .gitignore) que le dice a Cursor qué rutas excluir del contexto de la IA y de la indexación de la base de código. Importa porque, por defecto, cualquier cosa abierta en el espacio de trabajo puede arrastrarse al contexto del modelo, incluidos archivos .env, configuraciones y cadenas de conexión. Un .cursorignore bien mantenido es la palanca principal que mantiene los secretos y los módulos sensibles fuera del alcance del modelo. Uno desactualizado es la forma más común de que una credencial acabe en una petición de IA.

¿Debería activar Workspace Trust en Cursor?

Sí. Workspace Trust pone las funciones de ejecución de código de una carpeta abierta tras una decisión explícita de confianza. Es la mitigación directa para el fallo de septiembre de 2025, donde un repositorio con trampa podía autoejecutar una tarea y correr código en el momento en que abrías la carpeta. Como Cursor históricamente venía con Workspace Trust desactivado por defecto, activarlo debería ser una parte estándar de tu configuración inicial. Combínalo con abrir primero los repositorios no confiables en un entorno aislado (sandbox) o en un editor distinto.

¿Puede Cursor ejecutar código de un repositorio automáticamente?

Puede, si Workspace Trust está desactivado. Como fork de VS Code, Cursor respeta las tareas configuradas con runOn: folderOpen, así que un .vscode/tasks.json malicioso en un repositorio que clonas y abres puede ejecutarse de inmediato, sin aviso, en tu contexto de usuario. Esta fue la base del fallo de ejecución silenciosa de código informado en septiembre de 2025. Activar Workspace Trust cierra la brecha, pero el comportamiento por defecto es la razón por la que nunca deberías abrir un proyecto no confiable en tu instancia principal de Cursor.

¿Privacy Mode de Cursor lo hace seguro?

No, y es importante ser preciso aquí. Privacy Mode es un control de datos: garantiza que tu código no se almacena en los servidores de Cursor ni se usa para entrenamiento. No dice nada sobre la seguridad del código que Cursor genera, sobre si un repo puede autoejecutar una tarea, sobre si una inyección de prompts puede dirigir al agente, o sobre si un servidor MCP es malicioso. Privacy Mode protege tus datos; no protege tu aplicación. Sigues necesitando Workspace Trust, .cursorignore, SAST, revisión humana y un control en el momento del prompt.

¿En qué se diferencia la seguridad de Cursor de Claude Code, GitHub Copilot o Codex?

Los fundamentos son compartidos (privilegio mínimo, exclusión de secretos, revisión humana, análisis de dependencias), pero las superficies difieren. Los problemas distintivos de Cursor son que Workspace Trust venía desactivado por defecto y una alta tasa de código inseguro generado; el de Claude Code es la profunda integración con MCP y el shell; el de GitHub Copilot son las sugerencias inseguras y la fuga de secretos a escala; el de Codex son la inyección de comandos y los incidentes de cadena de suministro. Cubrimos cada agente en su propia guía: Claude Code, GitHub Copilot y OpenAI Codex.