Un audit de Cursor met au jour quatre failles dans la protection de l'éditeur de code, sans parvenir à contourner l'autorisation

L'audit de sécurité de Cursor aboutit à un résultat rare pour un outil d'AI : le chercheur n'a pas réussi à contourner l'autorisation côté serveur ni à accéder aux modèles premium via une faille du client, mais il a relevé en chemin quatre problèmes notables dans le périmètre de protection. L'intérêt de cette analyse tient précisément au fait qu'il ne s'agit pas d'une histoire où « tout est cassé », mais d'un examen détaillé du fonctionnement d'un éditeur AI qui fait transiter par ses serveurs d'importants volumes de code et de requêtes de développeurs.

L'étude a commencé par la décompilation du client Electron de Cursor, construit sur VS Code. Dans un seul fichier JavaScript minifié de plus de 1,1 million de lignes, l'auteur a reconstitué les définitions protobuf, la cartographie de l'API, la logique OAuth et la liste des feature gates. Il a également montré que le jeton JWT de l'utilisateur ne contient aucun claim relatif à l'abonnement ou à l'offre souscrite : les droits d'accès aux modèles ne sont vérifiés ni côté client ni via le contenu du jeton, mais sur le serveur, à partir des données en base.

Pour un produit SaaS exploitant des LLM coûteux, c'est un choix d'architecture décisif : c'est précisément ce schéma qui empêche un utilisateur « gratuit » de simplement modifier des paramètres locaux pour s'ouvrir l'accès à Claude 4 Opus ou à un autre modèle premium.

Après la rétro-ingénierie, le chercheur est passé aux attaques sur l'API. Première découverte : une prototype pollution dans les endpoints JSON liés à l'abonnement et aux promotions. Si l'on ajoute au corps de la requête des champs comme __proto__ ou constructor.prototype, le serveur renvoie une erreur 500 Internal Server Error au lieu du refus attendu. Cela ne permet pas d'obtenir automatiquement une offre supérieure, mais montre que la pollution de la prototype chain intervient avant les contrôles métier et peut modifier le chemin de validation.

Deuxième problème : le champ caché devRawModelSlug dans AgentRunRequest. Absent du schéma client, il est pourtant accepté par les serveurs de production, qui reconnaissent son nom et renvoient une erreur spécifique. Celle-ci révèle l'existence dans le système d'un mécanisme dev permettant de désigner directement un modèle backend en contournant le routing standard. Ce chemin est actuellement désactivé, mais sa seule présence dans le périmètre de production accroît le risque d'erreurs de configuration.

Les deux autres failles ne concernent plus le contournement de l'abonnement, mais une exposition excessive de l'architecture interne et une validation incomplète. L'une des méthodes internes répond par le message Invalid internal service header, qui permet de déduire que l'endpoint existe, qu'il est protégé par une autorisation service-to-service distincte et qu'il attend un en-tête spécifique. Un client externe n'a aucun besoin d'un tel niveau de détail : il serait plus sûr de renvoyer un 404 ou un 401 générique, sans indice interne.

Par ailleurs, l'audit montre que certains champs protobuf destinés aux scénarios de subagents acceptent des références à des modèles premium sans vérification spécifique de l'offre. En pratique, cela ne change pas le modèle qui produit réellement la réponse et n'ouvre aucun bypass, puisque le routing ignore de toute façon ces champs, mais cette logique élargit la surface d'attaque et pourrait poser problème après de futures évolutions du produit.

Un volet important de l'analyse porte sur les vecteurs qui n'ont pas fonctionné. L'auteur a testé le bruteforce des noms de modèles, la falsification des claims JWT, les injections dans le callback OAuth, le replay de webhooks Stripe, la confusion entre requested_model et model_details, les conflits de wire types dans protobuf et les race conditions autour de l'abonnement. Aucun contournement significatif n'a abouti.

Le serveur rejette les tags protobuf incorrects, ne fait pas confiance aux données du JWT, valide les signatures Stripe et centralise le plan check. La conclusion n'en est que plus solide : les problèmes existent bel et bien, mais le modèle de sécurité de base de Cursor paraît mature et réfléchi comparé à de nombreux services d'AI qui accordent trop de confiance au client.

La portée pratique de cette affaire dépasse Cursor. Pour les développeurs de SaaS d'AI, elle fournit une bonne checklist : ne pas stocker les privilèges dans le jeton, vérifier l'offre côté serveur à chaque requête, valider strictement le protobuf et ne pas laisser de champs dev dans les schémas de production. Pour les utilisateurs, c'est le signe que même les IDE AI les plus avancés conservent une surface vulnérable autour de la facturation, des services internes et des mécanismes techniques de routage des modèles.

Surtout, la sécurité d'un produit d'AI ne se mesure plus aujourd'hui au nombre de modèles qu'il prend en charge, mais à la rigueur avec laquelle il sépare le client des véritables droits d'accès sur le serveur.