Vulnérabilité dans GitHub Copilot et Cursor : comment les pirates peuvent compromettre le code généré par l'IA avec des portes dérobées et des vulnérabilités en injectant des instructions malveillantes cachéesLes chercheurs de Pillar Security annoncent la découverte d'une nouvelle vulnérabilité dans GitHub Copilot et Cursor. La nouvelle technique, appelée « Rules Files Backdoor », permettrait aux attaquants de manipuler les agents IA de codage par le biais de fichiers de règles compromis. La découverte d'une porte dérobée invisible pour les fichiers de règles expose des risques graves pour la chaîne d'approvisionnement de millions de développeurs qui utilisent des outils de codage assistés par l'IA, ce qui pourrait compromettre les écosystèmes logiciels dans le monde entier.
Des fichiers de configuration de règles ou fichiers de règles sont utilisés par les agents IA de codage pour guider leur comportement lors de la génération ou de l'édition de code. Par exemple, un fichier de règles peut contenir des instructions pour que l'assistant suive certaines bonnes pratiques de codage, utilise un formatage spécifique ou produise des réponses dans une langue spécifique.
Selon un récent rapport des chercheurs de Pillar Security, les assistants d'IA de codage tels que GitHub Copilot et Cursor pourraient être manipulés pour générer du code contenant des portes dérobées, des vulnérabilités et d'autres problèmes de sécurité via les fichiers de règles malveillants. La technique d'attaque mise au point par les chercheurs de Pillar, qu'ils appellent "Rules File Backdoor", arme les fichiers de règles en y injectant des instructions invisibles pour un utilisateur humain mais lisibles par l'agent IA.
Les configurations de règles sont souvent partagées entre les communautés de développeurs et distribuées par l'intermédiaire de dépôts open-source ou incluses dans des modèles de projet ; par conséquent, un attaquant pourrait distribuer un fichier de règles malveillant en le partageant sur un forum, en le publiant sur une plateforme open-source comme GitHub ou en l'injectant par l'intermédiaire d'une demande d'extraction dans un dépôt populaire. Une fois le fichier de règles empoisonné importé dans GitHub Copilot ou Cursor, l'agent IA lira et suivra les instructions de l'attaquant tout en aidant les futurs projets de codage de la victime.
Pour rappel, GitHub Copilot est un outil de complétion de code et de programmation automatique développé par GitHub et OpenAI qui aide les utilisateurs des environnements de développement intégré (EDI) Visual Studio Code, Visual Studio, Neovim et JetBrains en complétant automatiquement le code. Tandis que Cursor est un environnement de développement intégré (EDI) livré avec un assistant d'IA de codage. C'est un fork de Visual Studio Code qui s'appuie sur de grands modèles de langage (LLM) tels que Claude et GPT et offre des outils tels que la génération de code, l'autocomplétion intelligente et des réécritures de code optimisées.
Dans un exemple présenté par Pillar, un fichier de règles qui semblait indiquer à l'IA de "suivre les meilleures pratiques HTML5" comprenait un texte caché contenant des instructions supplémentaires pour ajouter un script externe à la fin de chaque fichier. L'invite cachée comprenait également un jailbreak pour contourner les contrôles de sécurité potentiels, assurant à l'IA que l'ajout du script était nécessaire pour sécuriser le projet et faisait partie de la politique de l'entreprise, ainsi que des instructions pour ne pas mentionner l'ajout du script dans les réponses à l'utilisateur.
Les chercheurs de Pillar ont constaté que GitHub Copilot et Cursor ont tous deux suivi les instructions d'ajout du script externe lorsqu'il leur a été demandé de générer une page HTML, et que l'ajout de ce script n'a pas été mentionné dans les réponses en langage naturel des assistants. Selon les chercheurs, le "Rules File Backdoor" pourrait également être utilisé pour introduire des vulnérabilités de sécurité dans le code généré ou pour créer du code qui laisse échapper des informations sensibles telles que des identifiants de base de données ou des clés d'API.
Pillar a révélé l'exploit à Cursor en février 2025 et à GitHub en mars 2025. Cursor a déclaré que le problème n'était pas dû à une vulnérabilité de sa plateforme et qu'il incombait aux utilisateurs de gérer le risque. GitHub a répondu de la même manière que les utilisateurs sont responsables de l'examen et de l'acceptation du code et des suggestions générés par Copilot.
Pillar recommande aux développeurs d'examiner tous les fichiers de règles qu'ils utilisent pour détecter d'éventuelles injections malveillantes, telles que des Unicodes invisibles ou un formatage inhabituel, et de traiter les fichiers de configuration de l'IA avec la même attention que le code exécutable. Le code généré par l'IA devrait également être examiné avec soin, en particulier pour détecter les ajouts inattendus tels que les références à des ressources externes, écrivent les chercheurs. Les outils de détection automatisés peuvent également aider à identifier les contenus suspects dans les fichiers de règles ou les indicateurs de compromission dans le code généré par l'IA.
Les chercheurs de Pillar Security présentent leurs découvertes :
Les chercheurs de Pillar Security ont découvert un nouveau vecteur d'attaque dangereux de la chaîne d'approvisionnement que nous avons baptisé « Rules File Backdoor ». Cette technique permet aux pirates de compromettre silencieusement le code généré par l'IA en injectant des instructions malveillantes cachées dans des fichiers de configuration apparemment innocents utilisés par Cursor et GitHub Copilot - les principaux éditeurs de code alimentés par l'IA dans le monde.*
En exploitant des caractères unicode cachés et des techniques d'évasion sophistiquées dans la charge utile d'instruction face au modèle, les acteurs de la menace peuvent manipuler l'IA pour insérer un code malveillant qui contourne les révisions de code habituelles. Cette attaque reste pratiquement invisible pour les développeurs et les équipes de sécurité, ce qui permet au code malveillant de se propager silencieusement dans les projets.
Contrairement aux attaques traditionnelles par injection de code qui ciblent des vulnérabilités spécifiques, le « Rules File Backdoor » représente un risque important en faisant de l'IA elle-même un vecteur d'attaque, transformant ainsi l'assistant le plus fiable du développeur en un complice involontaire, ce qui pourrait affecter des millions d'utilisateurs finaux par le biais de logiciels compromis.
En exploitant des caractères unicode cachés et des techniques d'évasion sophistiquées dans la charge utile d'instruction face au modèle, les acteurs de la menace peuvent manipuler l'IA pour insérer un code malveillant qui contourne les révisions de code habituelles. Cette attaque reste pratiquement invisible pour les développeurs et les équipes de sécurité, ce qui permet au code malveillant de se propager silencieusement dans les projets.
Contrairement aux attaques traditionnelles par injection de code qui ciblent des vulnérabilités spécifiques, le « Rules File Backdoor » représente un risque important en faisant de l'IA elle-même un vecteur d'attaque, transformant ainsi l'assistant le plus fiable du développeur en un complice involontaire, ce qui pourrait affecter des millions d'utilisateurs finaux par le biais de logiciels compromis.
Voici un extrait de la recherche de Pillar Security :
Nouvelle vulnérabilité dans GitHub Copilot et Cursor : Comment les pirates peuvent armer les agents de code
Les assistants de codage de l'IA en tant qu'infrastructure critique
Une enquête réalisée par GitHub en 2024 a révélé que presque tous les développeurs d'entreprise (97 %) utilisent des outils de codage d'IA générative. Ces outils sont rapidement passés du statut de nouveautés expérimentales à celui d'infrastructure de développement critique, les équipes du monde entier s'appuyant quotidiennement sur eux pour accélérer les tâches de codage.
Cette adoption généralisée crée une surface d'attaque importante. À mesure que ces assistants IA deviennent partie intégrante des flux de travail de développement, ils représentent une cible attrayante pour les acteurs de menaces sophistiquées qui cherchent à injecter des vulnérabilités à grande échelle dans la chaîne d'approvisionnement des logiciels.
Le fichier de règles comme nouveau vecteur d'attaque
En étudiant la manière dont les équipes de développement partagent la configuration de l'IA, les chercheurs en sécurité ont identifié une vulnérabilité critique dans la manière dont les assistants de codage de l'IA traitent les informations contextuelles contenues dans les fichiers de règles.
Qu'est-ce qu'un fichier de règles ?
Les fichiers de règles sont des fichiers de configuration qui guident le comportement des agents d'IA lors de la génération ou de la modification du code. Ils définissent les normes de codage, l'architecture du projet et les meilleures pratiques. Ces fichiers sont :
- Largement partagés : stockés dans des référentiels centraux accessibles à l'ensemble de l'équipe ou à l'échelle mondiale
- Largement adoptés : distribués par des communautés de logiciels libres et des dépôts publics
- Confiance implicite : Perçues comme des données de configuration inoffensives qui échappent à l'examen de sécurité
- Rarement validées : Intégrées dans des projets sans contrôle de sécurité adéquat
Voici un exemple de fichier de règles tiré de la documentation de Cursor :
Outre la création personnelle des fichiers, les développeurs peuvent également les trouver dans des communautés et des projets open-source sur Cursor ou GitHub.
Au cours de la recherche, il a été constaté que le processus de révision pour le téléchargement de nouvelles règles pour ces dépôts partagés est également vulnérable, car les caractères unicode cachés apparaissent également invisibles dans le processus d'approbation des demandes d'extraction de la plateforme GitHub.
Le mécanisme d'attaque
La recherche démontre que les attaquants peuvent exploiter la compréhension contextuelle de l'IA en intégrant des invites soigneusement conçues dans des fichiers de règles apparemment anodins. Lorsque les développeurs lancent la génération de code, les règles empoisonnées influencent subtilement l'IA pour qu'elle produise un code contenant des failles de sécurité ou des portes dérobées.
L'attaque s'appuie sur plusieurs mécanismes techniques :
- Manipulation contextuelle : Intégration d'instructions qui semblent légitimes mais qui incitent l'IA à modifier le comportement de génération de code.
- Obfuscation de l'Unicode : Utilisation de jointures de largeur nulle, de marqueurs de texte bidirectionnels et d'autres caractères invisibles pour dissimuler les instructions malveillantes.
- Détournement sémantique : Exploitation de la compréhension du langage naturel de l'IA au moyen de modèles linguistiques subtils qui redirigent la génération de code vers des implémentations vulnérables.
- Vulnérabilité inter-agents : L'attaque fonctionne avec différents assistants IA de codage, ce qui suggère une vulnérabilité systémique.
Ce qui rend le « Rules Files Backdoor » particulièrement dangereux, c'est sa nature persistante. Une fois qu'un fichier de règles empoisonné est incorporé dans le référentiel d'un projet, il affecte toutes les futures sessions de génération de code par les membres de l'équipe. En outre, les instructions malveillantes survivent souvent à la bifurcation du projet, créant ainsi un vecteur d'attaques de la chaîne d'approvisionnement qui peut affecter les dépendances en aval et les utilisateurs finaux.
Les chercheurs concluent en déclarant :
La technique du « Rules Files Backdoor » représente une évolution significative dans les attaques de la chaîne d'approvisionnement. Contrairement à l'injection de code traditionnelle qui exploite des vulnérabilités spécifiques, cette approche arme l'IA elle-même, transformant l'assistant le plus fiable d'un développeur en un complice involontaire.
À mesure que les outils IA de codage s'intègrent profondément dans les flux de travail de développement, les développeurs développent naturellement un « biais d'automatisation » - une tendance à faire confiance aux recommandations générées par l'ordinateur sans examen suffisant. Ce biais crée un environnement idéal pour que cette nouvelle classe d'attaques se développe.
Chez Pillar Security, nous pensons que la sécurisation du pipeline de développement de l'IA est essentielle pour préserver l'intégrité des logiciels. Les organisations doivent adopter des contrôles de sécurité spécifiques conçus pour détecter et atténuer les manipulations basées sur l'IA, en allant au-delà des pratiques traditionnelles d'examen du code qui n'ont jamais été conçues pour faire face à des menaces d'une telle sophistication.
L'ère du développement assisté par l'IA apporte des avantages considérables, mais nous oblige également à faire évoluer nos modèles de sécurité. Ce nouveau vecteur d'attaque démontre que nous devons désormais considérer l'IA elle-même comme une partie de la surface d'attaque qui nécessite une protection.
À mesure que les outils IA de codage s'intègrent profondément dans les flux de travail de développement, les développeurs développent naturellement un « biais d'automatisation » - une tendance à faire confiance aux recommandations générées par l'ordinateur sans examen suffisant. Ce biais crée un environnement idéal pour que cette nouvelle classe d'attaques se développe.
Chez Pillar Security, nous pensons que la sécurisation du pipeline de développement de l'IA est essentielle pour préserver l'intégrité des logiciels. Les organisations doivent adopter des contrôles de sécurité spécifiques conçus pour détecter et atténuer les manipulations basées sur l'IA, en allant au-delà des pratiques traditionnelles d'examen du code qui n'ont jamais été conçues pour faire face à des menaces d'une telle sophistication.
L'ère du développement assisté par l'IA apporte des avantages considérables, mais nous oblige également à faire évoluer nos modèles de sécurité. Ce nouveau vecteur d'attaque démontre que nous devons désormais considérer l'IA elle-même comme une partie de la surface d'attaque qui nécessite une protection.
Fait intéressant, un rapport récent confirmait l'impact des données injectées dans l'IA. Un programmeur avait rapporté que Cursor AI a brusquement refusé de continuer à générer du code et a appelé le développeur à continuer à coder manuellement. Après analyse, certains ont montré la forte ressemblance de la réponse de l'IA aux conseils retrouvés sur les sites Web communautaires d'aide à la programmation comme Stack Overflow.
Selon le rapport, la ressemblance n'est pas surprenante. Les grands modèles de langage qui pilotent des outils tels que Cursor AI sont formés sur des ensembles de données massifs qui comprennent des millions de discussions de codage provenant de plateformes telles que Stack Overflow et GitHub. Ces modèles ne se contentent pas d'apprendre la syntaxe de programmation ; ils absorbent aussi les normes culturelles et les styles de communication de ces communautés.
Source : Pillar Security
Et vous ?
Pensez-vous que cette découverte est crédible ou pertinente ? Quel est votre avis sur le sujet ?Voir aussi :
ChatGPT génère un code informatique peu sûr, mais ne vous le dira pas à moins que vous ne le lui demandiez. Les experts mettent en garde contre les risques d'une surconfiance en ChatGPT L'outil d'IA GitHub Copilot améliore-t-il la qualité du code ? Si GitHub estime que le code produit est plus fonctionnel. GitClear note que cela peut entraîner « une dette technique induite par l'IA » L'IA peut écrire du code mais ne parvient pas à le comprendre, selon une étude d'OpenAI. Testés sur des tâches réelles de programmation, les modèles les plus avancés n'ont pu résoudre qu'un quart des défis
Vous avez lu gratuitement 0 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
