Cursor ne stocke pas les clés API dans un espace de stockage protégé, ce qui signifie que n'importe quelle extension peut y accéder. Cursor était au courant de cette vulnérabilité mais ne l'a pas corrigée.

Préface

Les chercheurs en sécurité de LayerX ont découvert que toute extension de l'outil de développement d'IA populaire Cursor peut accéder aux clés API et aux jetons de session du développeur, ce qui conduit à une compromission totale des identifiants, sans aucune interaction ni activité de l'utilisateur. 

LayerX a découvert que, puisque Cursor ne stocke pas les clés dans un espace de stockage protégé, tout L'extension Cursor peut effectuer cet accès. Par conséquent, chaque utilisateur de Cursor est vulnérable au vol de clés API par des extensions Cursor malveillantes.

L'exploitation de cette vulnérabilité peut entraîner la divulgation des jetons de session et des clés API, l'accès non autorisé aux services backend de Cursor et le vol de données par usurpation d'identité de l'utilisateur.

LayerX a signalé cette vulnérabilité à Cursor. Cursor a répondu être au courant du problème, mais a précisé qu'il incombait à l'utilisateur de définir ses limites de confiance. À ce jour, Cursor n'a pas corrigé ce problème.

 

Les clés API du curseur sont stockées dans une base de données locale ouverte.

Cursor, un environnement de développement populaire basé sur l'IA, contient une vulnérabilité de contrôle d'accès de haute gravité (CVSS 8.2) qui permet à toute extension installée d'accéder aux informations d'identification sensibles stockées localement.

Contrairement aux pratiques de sécurité standard où les secrets tels que les clés API et les jetons de session sont stockés dans un espace de stockage protégé (par exemple, les trousseaux du système d'exploitation), Cursor stocke ces informations d'identification dans une base de données SQLite locale :

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

Point crucial, Cursor n'impose aucune restriction d'accès entre les extensions et cette base de données. Par conséquent, n'importe quelle extension, quelles que soient ses permissions déclarées, peut y accéder directement et extraire des données sensibles.

Cela crée une primitive d'attaque puissante : une extension Cursor malveillante ou compromise peut exfiltrer silencieusement des clés API et des jetons de session, permettant la prise de contrôle de compte, l'accès aux données et l'abus financier.

 

Impact

Cette vulnérabilité permet une compromission totale des identifiants sans aucune interaction de l'utilisateur (hormis l'installation d'une extension), ce qui entraîne :

  • Exposition des jetons de session et des clés API
  • Accès non autorisé aux services backend de Cursor
  • Compromission des intégrations tierces (par exemple, OpenAI, Anthropic, Google)
  • Usurpation d'identité et accès aux données

Risque en aval (Exemple : vol de clés API OpenAI)

Si un attaquant obtient la clé API OpenAI d'une victime, il peut :

  • Exécution d'appels API facturés à la victime → perte financière
  • Invites d'accès, champs à remplir et métadonnées → exposition des données
  • Utiliser l'API à des fins d'attaques ou d'automatisation supplémentaires
  • Il est possible de déduire des informations sensibles à partir d'interactions antérieures.

Étant donné que ces clés offrent souvent un large accès, leur impact s'étend au-delà de Cursor lui-même, englobant l'écosystème d'IA et de développement plus vaste de l'utilisateur.

 

Présentation technique

Passons en revue un scénario d'attaque réaliste du point de vue de l'attaquant.

Figure 1. Flux d'exploitation

Étape 1 : Préparation de l'extension malveillante

Un attaquant crée une extension de curseur apparemment inoffensive – un outil de productivité, un thème ou un utilitaire, par exemple. Elle ne demande aucune autorisation suspecte et semble sans danger à installer.

Du point de vue de l'utilisateur, rien ne semble anormal.

Étape 2 : L'utilisateur installe l'extension

Un développeur installe l'extension depuis une plateforme de vente ou un dépôt GitHub.

Il y a:

  • Pas d'avertissement
  • Aucune demande d'autorisation relative à l'accès aux identifiants.
  • Aucun signe de risque

À ce stade, l'attaquant a exécuté du code au sein de l'environnement d'extension Cursor.

Étape 3 : Accès au stockage sensible

Cursor stocke les données sensibles dans une base de données SQLite locale mentionnée ci-dessus. Cette base de données contient :

  • jetons de session
  • Clés API (par exemple, OpenAI)
  • Autres artefacts d'authentification

En raison de l'absence de contrôle d'accès, l'extension peut ouvrir et interroger directement cette base de données. Aucun privilège particulier n'est requis.

Étape 4 : Extraction des identifiants

L'extension analyse la base de données et extrait :

  • Clés API
  • jetons de session
  • Configuration ou métadonnées éventuellement mises en cache

Figure 2. Exemple de requête de base de données de l'extension PoC

Comme les données sont stockées en clair (ou insuffisamment protégées), leur extraction est simple.

Étape 5 : Exfiltration silencieuse

L'extension envoie les identifiants volés à un serveur contrôlé par l'attaquant, ce qui peut se faire par une simple requête. Cette opération se déroule de manière silencieuse.

  • Aucune interaction de l'utilisateur requise
  • Aucune modification visible de l'interface utilisateur
  • Aucune alerte

Étape 6 : Post-exploitation

L'attaquant possède désormais des identifiants valides.

Pourquoi ce cas est considéré comme très grave

Cette vulnérabilité est particulièrement dangereuse car :

  • Aucune autorisation requise
  • Aucune intervention de l'utilisateur n'est requise après l'installation. 
  • Faible complexité d'attaque
  • Impact sur la confidentialité élevée

Pour montrer à quel point cette faille peut être facilement exploitée, nous avons créé un Extension de preuve de concept et une vidéo de démonstration :

 

Chronologie de la divulgation :

Bien que le rapport démontre que les extensions peuvent accéder à la base de données SQLite locale contenant les identifiants, cet accès est limité à la machine locale sur laquelle l'utilisateur a déjà installé l'extension et lui a accordé les autorisations nécessaires. Cela représente la même limite de confiance que pour toute autre application locale : des extensions malveillantes ayant accès au système de fichiers local pourraient potentiellement accéder à diverses bases de données d'applications.

  • État de la correctionNon résolu. Mar., 28 avr. 2026 

Mesures correctives recommandées

Pour résoudre correctement ce problème, Cursor doit :

  • Imposer une isolation stricte entre les extensions et le stockage des informations d'identification sensibles.
  • Les informations d'identification sensibles doivent être gérées via une couche de stockage sécurisée et chiffrée ou un trousseau au niveau du système (par exemple, le Trousseau d'accès macOS, le Gestionnaire d'informations d'identification Windows).