L'Audit de Sécurité de Cursor Découvre Quatre Vulnérabilités dans l'Éditeur de Code, mais l'Autorisation Reste Sécurisée

Un audit de sécurité de Cursor a révélé un résultat rare pour les outils IA : le chercheur n'a pas pu contourner l'autorisation côté serveur et accéder aux modèles premium via une vulnérabilité côté client, mais a trouvé quatre problèmes notables dans le périmètre de sécurité en chemin. L'examen est intéressant précisément parce que ce n'est pas une histoire sur « tout s'est cassé », mais plutôt un examen détaillé de la façon dont un éditeur de code IA est structuré—un qui canalise de grands volumes de code et de demandes de développeurs via ses serveurs. L'investigation a commencé par la décompilation du client Electron de Cursor, construit sur VS Code.

Dans un seul fichier JavaScript minifié dépassant 1,1 million de lignes, l'auteur a récupéré les descriptions protobuf, une carte API, la logique OAuth et une liste de feature gates. Séparément, il a démontré que le jeton JWT de l'utilisateur ne contient aucun claim concernant la souscription ou le forfait : les droits d'accès aux modèles ne sont pas vérifiés côté client et non via le contenu du jeton, mais sur le serveur, en fonction des données de la base de données. Pour un produit SaaS avec des LLM coûteux, c'est un choix architectural clé, précisément parce qu'un tel schéma empêche un utilisateur « gratuit » de simplement falsifier les paramètres locaux et de déverrouiller Claude 4 Opus ou un autre modèle premium.

Après l'ingénierie inverse de l'API, le chercheur a procédé à des attaques sur l'API. La première découverte—pollution de prototype dans les endpoints JSON liés à la souscription et aux promotions. Si des champs comme __proto__ ou constructor.

prototype sont ajoutés au corps de la requête, le serveur retourne une erreur 500 Internal Server Error au lieu du rejet attendu. Cela n'accorde pas de mises à niveau automatiques de forfait, mais montre que la pollution de la chaîne de prototypes se produit avant les vérifications de la logique métier et peut altérer le chemin de validation. Le deuxième problème—un champ caché devRawModelSlug dans AgentRunRequest.

Il n'existe pas dans le schéma client, mais les serveurs de production acceptent ce champ, reconnaissent son nom et répondent par une erreur séparée qui révèle que le système possède un mécanisme dev pour spécifier directement le modèle backend, contournant le routage standard. Actuellement ce chemin est désactivé, mais sa simple présence dans le périmètre de production augmente le risque d'erreurs de configuration. Deux autres vulnérabilités résultent non pas du contournement de souscription, mais de l'exposition inutile de l'architecture interne et d'une validation incomplète.

Une méthode interne répond par « Invalid internal service header », d'où on peut déduire que l'endpoint existe, est protégé par une autorisation séparate de service à service, et s'attend à un en-tête spécial. Pour un client externe, un tel détail est inutile : il serait plus sûr de répondre par un 404 ou 401 universel sans indices internes. De plus, l'audit a révélé que certains champs protobuf pour les scénarios de subagent acceptent des liens vers des modèles premium sans vérification de forfait séparate.

En pratique, cela ne modifie pas le modèle de réponse réel et n'ouvre pas de contournement, car le routage ignore de toute façon ces champs, mais une telle logique élargit la surface d'attaque et pourrait devenir un problème après les futurs changements de produit. Une partie importante de l'examen—une liste des vecteurs qui n'ont pas fonctionné. L'auteur a testé la force brute des noms de modèles, l'usurpation de claims JWT, l'injection de callback OAuth, la relecture du webhook Stripe, la confusion entre requested_model et model_details, les conflits de types de wire protobuf et les conditions de course autour de la souscription.

Aucun contournement significatif n'a réussi nulle part. Le serveur rejette les tags protobuf incorrects, ne fait pas confiance aux données JWT, valide les signatures Stripe et maintient les vérifications de forfait centralisées. Cela renforce la conclusion : des problèmes existent réellement, mais le modèle de sécurité de base de Cursor semble mûr et réfléchi comparé à de nombreux services IA qui font trop confiance au client.

La signification pratique de cette histoire s'étend au-delà de Cursor lui-même. Pour les développeurs d'IA SaaS, ceci est une bonne liste de contrôle : ne stockez pas les privilèges dans les jetons, vérifiez le forfait sur le serveur à chaque requête, validez strictement protobuf, et ne laissez pas de champs dev dans les schémas de production. Pour les utilisateurs, c'est un signal que même les IDEs avancés d'IA ont une surface vulnérable autour de la facturation, des services internes et des mécanismes de routage des modèles.

Et surtout : aujourd'hui, la sécurité d'un produit IA est définie non pas par le nombre de modèles qu'il supporte, mais par la discipline avec laquelle il sépare le client des droits d'accès réels sur le serveur.