Le plugin Copilot pour JetBrains : un nom de ressource malformé peut exécuter du code
Un avis Microsoft du 14 juillet 2026 décrit une faille du plugin GitHub Copilot pour les IDE JetBrains où un nom de ressource non validé, livré via du contenu que l'assistant traite, peut mener à l'exécution de code local sur la machine d'un développeur.
De quoi s’agit-il ?
Le 14 juillet 2026, dans le cadre de son Patch Tuesday, Microsoft a publié un avis concernant une vulnérabilité de gravité élevée dans le plugin GitHub Copilot pour les IDE JetBrains — l’extension qui intègre Copilot à IntelliJ IDEA, PyCharm, WebStorm, Rider, Android Studio et le reste de la famille JetBrains. Microsoft la note CVSS 7,8 (« élevée ») et la qualifie d’exécution de code à distance, bien que le vecteur d’attaque soit local. Toutes les versions du plugin antérieures à 1.13.0-251 sont concernées, et un correctif est déjà disponible sur le JetBrains Marketplace.
La cause racine est banale, et c’est précisément ce qui la rend instructive : le plugin ne contraint ni ne valide suffisamment les noms de fichiers et d’autres ressources qu’il traite ensuite (la classe de faiblesse citée par Microsoft est CWE-641, restriction inadéquate des noms de fichiers et de ressources). Un nom de ressource passe d’ordinaire inaperçu — mais lorsqu’un assistant IA ingère le contenu d’un projet et agit dessus, un nom contrôlé par l’attaquant devient une entrée contrôlée par l’attaquant pour ce qui le consomme.
Comment ça marche
L’avis de Microsoft reste volontairement discret sur le mécanisme : il ne nomme pas la fonctionnalité précise de Copilot qui traite mal le nom de ressource, ne fournit aucune preuve de concept et ne liste aucun indicateur de compromission. Ce que le vecteur CVSS indique dessine néanmoins des limites claires. L’attaque ne nécessite aucun privilège, est de faible complexité et exige une interaction de l’utilisateur — le développeur doit ouvrir quelque chose ou interagir avec. Un exploit réussi compromet ensuite la confidentialité, l’intégrité et la disponibilité de la machine locale.
Le cadrage « à distance mais local » est le point à intégrer. Personne ne peut scanner Internet et atteindre directement un IDE vulnérable. Le nom de ressource malveillant doit arriver dans du contenu que le développeur choisit de manipuler : un dépôt cloné, un projet d’exemple alléchant, une pull request, une mise à jour de dépendance, un fichier déposé dans un gestionnaire de tickets ou une messagerie. L’action ordinaire de la victime — ouvrir le projet, laisser Copilot le lire — est le pont qui transforme la livraison distante en exécution locale. C’est le même schéma « contenu non fiable devenu instruction » qui a nourri une année de découvertes sur les agents de code ; ici il ne passe pas par un prompt astucieux mais par un nom que le plugin ne parvient pas à assainir.
Comme l’analyse technique n’est pas encore publique et qu’aucun exploit ne circule, cet article s’en tient au niveau confirmé par Microsoft. Nous décrivons une classe de défaillance et sa surface de livraison, pas un exploit fonctionnel.
Pourquoi c’est important
Les postes de développeurs comptent parmi les machines les plus sensibles d’une organisation. Ils hébergent du code source, des identifiants Git, des clés SSH, des sessions de CLI cloud, des jetons de registres de paquets, du matériel de signature et, souvent, des accès directs aux pipelines CI/CD. L’exécution de code sous l’identité d’un développeur reste rarement cantonnée à l’éditeur ; elle hérite de tout ce que ce compte et ce réseau peuvent atteindre.
Le problème de distribution aggrave la situation. Les plugins JetBrains sont souvent installés et mis à jour par les développeurs eux-mêmes, hors de la gestion centralisée des correctifs. Déployer la mise à jour mensuelle du système d’exploitation ne change rien à un plugin Copilot vulnérable, car il s’agit d’une faille au niveau du produit, dans l’extension elle-même. Un seul poste non corrigé qui clone et compile le code d’un client suffit à peser. La découverte s’inscrit aussi dans une tendance plus large : à mesure que Copilot passe de l’autocomplétion à un agent qui lit les projets, appelle des outils et modifie des fichiers, les données auxquelles il fait confiance deviennent une cible plus riche — et un nom malformé dans un fichier d’apparence anodine est exactement le type d’entrée qu’on avait l’habitude d’ignorer.
Défenses
L’avis apporte de bonnes nouvelles aux défenseurs : l’exploit n’est pas public, l’évaluation SSVC initiale de la CISA le classe « aucune exploitation connue » et « non automatisable », et le correctif est une simple mise à jour. Cela laisse une réelle fenêtre pour agir.
-
Mettez à jour le plugin. Passez le plugin GitHub Copilot pour JetBrains en 1.13.0-251 ou ultérieure. Vérifiez la version manuellement dans Paramètres/Préférences → Plugins plutôt que de compter sur la mise à jour automatique, surtout là où les développeurs la désactivent pendant les sprints.
-
Inventoriez, ne supposez pas. Traitez cela comme une campagne de correctif au niveau plugin. Recensez chaque poste exécutant un IDE JetBrains avec Copilot — y compris les installations poussées par synchronisation de paramètres ou par un dépôt de plugins géré — et confirmez la version sur chacun.
-
Contenez le vecteur de livraison. En attendant le correctif, évitez de cloner ou d’ouvrir des dépôts inconnus, des projets d’exemple et du code de sources non vérifiées. Désactiver le plugin Copilot supprime entièrement le composant vulnérable si une mise à jour ne peut être déployée immédiatement.
-
Moindre privilège pour les comptes développeurs. Exécutez les IDE en utilisateur standard, non en administrateur local, et privilégiez des jetons courts et à portée limitée pour GitHub et les fournisseurs cloud, afin de réduire le rayon d’impact d’une exécution de code sous l’identité du développeur.
-
Surveillez les anomalies, avec prudence. Sans IOC fournis par l’éditeur, guettez les processus enfants inattendus lancés par les processus de l’IDE JetBrains — un interpréteur Python ou Node démarré juste après l’ouverture d’un projet inconnu — ou des connexions sortantes inhabituelles. Traitez ces signaux comme des pistes, pas des alertes, car un développement normal produit un bruit similaire.
À noter : les bacs à sable de Copilot en préversion publique (juin 2026) relèvent de la défense en profondeur, mais l’avis n’affirme pas qu’ils atténuent cette faille précise. Corrigez d’abord.
Statut
| Élément | Référence | Date | Notes |
|---|---|---|---|
| Avis Microsoft (CVE-2026-50510) | MSRC | 2026-07-14 | Plugin GitHub Copilot pour IDE JetBrains ; CVSS 7,8 (élevée) |
| Classe de faiblesse | MSRC / CWE-641 | 2026-07-14 | Restriction inadéquate des noms de fichiers et de ressources |
| Vecteur d’attaque | Vecteur CVSS | 2026-07-14 | Local, faible complexité, aucun privilège, interaction utilisateur requise |
| Version corrigée | JetBrains Marketplace | 2026-07-14 | 1.13.0-251 et ultérieures |
| État de l’exploitation | CISA SSVC | 2026-07-15 | Aucune exploitation connue ; non automatisable ; pas de PoC ni d’IOC public |
À retenir : Copilot n’est pas dangereux par nature. Le point clé, c’est qu’un nom de ressource devient une entrée non fiable dès qu’un assistant IA le lit dans un projet — et la même discipline de validation que nous appliquons aux compilateurs, aux scripts de build et aux harnais de test doit désormais s’étendre aux outils qui écrivent notre code.