Cursor no almacena las claves API en un almacenamiento protegido, lo que significa que cualquier extensión puede acceder a ellas. Cursor conocía esta vulnerabilidad, pero no la solucionó.

Resumen Ejecutivo

Los investigadores de seguridad de LayerX han descubierto que cualquier extensión de la popular herramienta de desarrollo de IA Cursor puede acceder a las claves API y los tokens de sesión del desarrollador, lo que conlleva una vulneración total de las credenciales, sin necesidad de interacción ni actividad alguna por parte del usuario. 

LayerX descubrió que, dado que Cursor no almacena las claves en un almacenamiento protegido, cualquier La extensión Cursor puede ejecutar este acceso. Como resultado, todos los usuarios de Cursor son vulnerables al robo de claves API por parte de extensiones de Cursor maliciosas.

La explotación de esta vulnerabilidad puede conllevar la exposición de tokens de sesión y claves API, el acceso no autorizado a los servicios de backend de Cursor y el robo de datos mediante la suplantación de identidad de usuarios.

LayerX informó de esta vulnerabilidad a Cursor. Cursor respondió que reconocen el problema, pero que es responsabilidad del usuario definir sus límites de confianza. Hasta la fecha, Cursor no ha solucionado este problema.

 

Las claves de la API del cursor se almacenan en una base de datos local y abierta.

Cursor, un entorno de desarrollo popular impulsado por IA, contiene una vulnerabilidad de control de acceso de alta gravedad (CVSS 8.2) que permite que cualquier extensión instalada acceda a credenciales confidenciales almacenadas localmente.

A diferencia de las prácticas de seguridad estándar, donde los secretos como las claves API y los tokens de sesión se almacenan en un almacenamiento protegido (por ejemplo, llaveros del sistema operativo), Cursor almacena estas credenciales en una base de datos SQLite local:

` ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb `

Es fundamental destacar que Cursor no impone límites de control de acceso entre las extensiones y esta base de datos. Como resultado, cualquier extensión, independientemente de sus permisos declarados, puede leerla directamente y extraer datos confidenciales.

Esto crea una poderosa herramienta de ataque: una extensión de Cursor maliciosa o comprometida puede extraer silenciosamente claves de API y tokens de sesión, lo que permite el robo de cuentas, el acceso a datos y el abuso financiero.

 

Impacto

Esta vulnerabilidad permite el acceso no autorizado a las credenciales sin interacción del usuario (más allá de la instalación de una extensión), lo que conlleva a:

  • Exposición de tokens de sesión y claves API
  • Acceso no autorizado a los servicios de backend de Cursor
  • Compromiso con las integraciones de terceros (por ejemplo, OpenAI, Anthropic, Google)
  • Suplantación de identidad de usuario y acceso a datos

Riesgos posteriores (Ejemplo: Robo de claves API de OpenAI)

Si un atacante obtiene la clave API de OpenAI de una víctima, puede:

  • Ejecutar llamadas a la API facturadas a la víctima → pérdida financiera
  • Acceso a indicaciones, autocompletado y metadatos → exposición de datos
  • Abusar de la API para realizar más ataques o automatizaciones.
  • Potencialmente, se puede inferir información sensible a partir de interacciones previas.

Dado que estas claves suelen otorgar un acceso amplio, el impacto se extiende más allá de Cursor y abarca el ecosistema de IA y desarrollo más amplio del usuario.

 

Resumen técnico

Analicemos un escenario de ataque realista desde la perspectiva del atacante.

Figura 1. Flujo de explotación

Paso 1: Preparación de la extensión maliciosa

Un atacante crea una extensión de Cursor aparentemente inofensiva, como una herramienta de productividad, un tema o una utilidad auxiliar. No solicita permisos sospechosos y parece segura de instalar.

Desde la perspectiva del usuario, nada parece inusual.

Paso 2: El usuario instala la extensión.

Un desarrollador instala la extensión desde un mercado o un repositorio de GitHub.

Hay

  • Sin advertencia
  • No se solicitó permiso para acceder a las credenciales.
  • No hay indicios de riesgo

En este punto, el atacante tiene capacidad de ejecución de código dentro del entorno de extensión Cursor.

Paso 3: Acceso al almacenamiento sensible

Cursor almacena datos confidenciales en la base de datos SQLite local mencionada anteriormente. Esta base de datos contiene:

  • tokens de sesión
  • Claves API (por ejemplo, OpenAI)
  • Otros artefactos de autenticación

Debido a la falta de control de acceso, la extensión puede abrir y consultar directamente esta base de datos. No se requieren privilegios especiales.

Paso 4: Extracción de credenciales

La extensión analiza la base de datos y extrae:

  • Claves API
  • tokens de sesión
  • Posiblemente configuración o metadatos almacenados en caché.

Figura 2. Ejemplo de consulta de base de datos de la extensión PoC.

Dado que los datos se almacenan en texto plano (o con una protección insuficiente), su extracción es sencilla.

Paso 5: Exfiltración silenciosa

La extensión envía las credenciales robadas a un servidor controlado por el atacante, lo cual se puede hacer con una simple solicitud de obtención de credenciales. Esto sucede de forma silenciosa:

  • No se requiere interacción del usuario
  • No se observan cambios en la interfaz de usuario.
  • Sin alertas

Paso 6: Post-explotación

El atacante ahora posee credenciales válidas.

¿Por qué esto es de alta gravedad?

Esta vulnerabilidad es particularmente peligrosa porque:

  • No se requieren permisos
  • No se requiere interacción del usuario después de la instalación. 
  • Baja complejidad de ataque
  • Impacto de alta confidencialidad

Para resaltar la facilidad con la que esto puede ser explotado, creamos un Extensión PoC y un vídeo de demostración:

 

Cronograma de divulgación:

Si bien el informe demuestra que las extensiones pueden acceder a la base de datos SQLite local que contiene las credenciales, este acceso se limita a la máquina local donde el usuario ya instaló la extensión y le otorgó los permisos necesarios. Esto representa el mismo nivel de confianza que cualquier otra aplicación local: las extensiones maliciosas con acceso al sistema de archivos local podrían acceder a diversos almacenes de datos de aplicaciones.

  • Estado de corrección: No solucionado. Mar, 28 de abril de 2026 

Remediación recomendada

Para abordar correctamente este problema, Cursor debe:

  • Garantizar un aislamiento estricto entre las extensiones y el almacenamiento de credenciales confidenciales.
  • Las credenciales confidenciales deben gestionarse mediante una capa de almacenamiento segura y cifrada o un llavero a nivel de sistema (por ejemplo, el Llavero de macOS o el Administrador de credenciales de Windows).