Utilisez-vous des assistants IA pour coder ? Vos données pourraient être en danger, selon le rapport IDEsaster

L’enquête de sécurité la plus inquiétante de l’année vient de révéler une découverte qui pourrait ébranler la confiance dans les outils d’IA. Plus précisément, cela affecte bon nombre de ceux que des millions de développeurs utilisent quotidiennement. L'événement, déjà connu sous le nom de « IDEsaster », est un nouveau type d'attaque qui expose une vulnérabilité systémique dans chacun des assistants de code…

six mois d'un recherche rigoureuse ont révélé plus de 30 vulnérabilités indépendantes réparties parmi plusieurs des produits d’IA les plus utilisés : GitHub Copilot, Cursor, Windsurf, Claude Code, Gemini CLI, JetBrains Junie, Zed.dev, Roo Code et Cline.

Mais ce qui inquiète le plus les utilisateurs n’est pas le nombre de failles de sécurité découvertes, mais plutôt leur nature. Et IDEsaster n'exploite pas les composants spécifiques des applications, mais les fonctionnalités héritées des environnements de développement qui, jusqu'à présent, fonctionnaient sans problème depuis des années. Avant même que les assistants IA n’existent. Dès lors que vous ajoutez un agent IA autonome capable d’agir sans surveillance humaine, ces mêmes caractéristiques deviennent des armes…

C'est la chaîne d'attaque IDEsaster

La capacité destructrice d'IDESAster se retrouve dans une architecture où l'on retrouve 3 phases parfaitement différenciées.

Premièrement, les attaquants injectent des instructions malveillantes dans le contexte de l'agent IA à l'aide de plusieurs vecteurs. Cela peut se produire via des fichiers de configuration manipulés, des serveurs MCP compromis, des liens modifiés ou même des noms de fichiers soigneusement conçus. L'agent IA, pleinement convaincu d'opérer dans un environnement sûr, obéit à ces instructions ainsi qu'aux demandes légitimes de l'utilisateur, et c'est ici que commence la deuxième phase.

Principaux services concernés par le « IDEsaster ». Photo : maccarita.com

Dans cette deuxième étape, l'agent utilise ses outils intégrés pour exécuter des actions qui déclenchent des fonctionnalités héritées de l'EDI de base que personne ne considérait comme dangereuses.

Enfin, dans la troisième phase, ces anciennes fonctionnalités, mais toujours fonctionnelles dans les environnements de développement, sont exploitées pour atteindre deux objectifs. Tout d’abord, la fuite de données sensibles ou l’exécution de code manipulé sur le PC du développeur. Les chercheurs ont démontré l’efficacité de ces attaques à partir de trois cas particulièrement importants :

  • Les attaques JSON Schema exploitent Visual Studio Code, les IDE JetBrains et Zed.dev pour extraire des données en déclenchant des requêtes GET vers des serveurs contrôlés par les attaquants.
  • Les vulnérabilités de remplacement de la configuration de l'IDE permettent l'exécution de code à distance en manipulant des fichiers tels que « .vscode/settings.json » ou « .idea/workspace.xml » pour injecter des commandes.
  • Les configurations d'espace de travail dans Visual Studio Code élargissent encore la surface d'attaque, permettant une manipulation de configuration qui contourne les contrôles de sécurité

La réponse de l'industrie et des utilisateurs

Les fournisseurs des services concernés (GitHub Copilot, Claude Code, Gemini…) sont déjà conscients de cette vulnérabilité, mais n'ont pas encore réussi à répondre de manière cohérente à ces découvertes. Depuis GitHub Copilot, des vulnérabilités telles que CVE-2025-53773 et CVE-2025-64660 ont été corrigées avec des correctifs implémentés.

De son côté, Cursor a également reçu des correctifs pour CVE-2025-49150, CVE-2025-54130 et CVE-2025-61590. De même, des produits comme Kiro.dev ou Roo Code ont également publié ces mêmes correctifs.

Cependant, les réponses de certains fournisseurs importants comme Claude Code (d'Anthropic) ont inquiété les utilisateurs. Et ils ont choisi de faire face aux risques uniquement par avertissements de sécurité au lieu d'apporter des modifications fondamentales au code. Les chercheurs à l'origine de cet événement ont quant à eux introduit un nouveau principe de sécurité sous le nom de « Secure for AI », qui étend les principes de conception sécurisée aux outils d'intelligence artificielle.

De leur côté, les développeurs doivent désormais limiter l’utilisation des IDE IA aux seuls projets auxquels ils peuvent faire confiance à 100 %. De même, ils doivent également examiner méticuleusement les serveurs MCP. Mais le défi le plus important n’a toujours pas été résolu : les fonctionnalités héritées conçues spécifiquement pour les utilisateurs humains deviennent mortelles lorsque des agents autonomes y ont accès.