Opus 5 aurait résolu l'injection de prompt via navigateur, la faille de sécurité qui hante les agents IA

Les agents IA de GitHub peuvent faire fuiter un dépôt privé via une injection de prompt

Des chercheurs en sécurité de l'entreprise Noma ont démontré une faille baptisée GitLost dans les GitHub Agentic Workflows, la fonctionnalité d'agents IA de GitHub lancée en préversion publique le 11 juin dernier. En se faisant passer pour un vice-président des ventes, les chercheurs ont ouvert un simple ticket de rapport d'erreur sur un dépôt public, glissant au milieu du message une question anodine en apparence sur le contenu du fichier README de deux dépôts privés de la même organisation, nommés « poc » et « testlocal ». Dès que le ticket a été attribué à l'agent IA, celui-ci a récupéré le contenu de ces fichiers privés et l'a recopié directement dans sa réponse publique au ticket, rendant ainsi accessible à tous une information censée rester confidentielle. Selon Noma, c'est l'ajout d'un simple mot de transition, « Additionally », qui a suffi à faire basculer l'agent d'une tâche légitime vers l'exécution de la requête malveillante cachée dans le message. Cette découverte fragilise un peu plus la confiance des développeurs envers GitHub, qui avait pourtant présenté ses agents comme fortement sécurisés. Lancée en février dernier et utilisable avec Copilot CLI, Claude Code ou OpenAI Codex au choix, la fonctionnalité permet d'automatiser la gestion de documentation, de tickets de bugs ou de tests via les GitHub Actions. L'entreprise assurait disposer de plusieurs niveaux de protection : permissions en lecture seule par défaut, exécution en conteneur sandbox derrière un « Agent Workflow Firewall », filtre d'intégrité, validation des résultats et détection automatique des menaces sur toute modification proposée. La démonstration de Noma montre que ces garde-fous peuvent être contournés par une injection de prompt relativement simple, sans exploiter de faille technique complexe, ce qui pose un problème direct pour toute organisation ayant activé ces agents sur des dépôts mêlant contenus publics et privés. L'épisode illustre ce que l'ingénieur Simon Willison appelle le « trio mortel » des agents IA : l'accès à des données confidentielles, le traitement de contenus non fiables provenant de tiers, et la capacité à faire sortir de l'information vers l'extérieur. Dès lors que ces trois conditions sont réunies, comme c'est le cas avec un agent capable de lire des dépôts privés tout en traitant des tickets ouverts par n'importe quel utilisateur externe, l'injection de prompt devient une voie d'attaque quasiment inévitable. GitHub n'a pas encore communiqué publiquement de correctif spécifique face à cette démonstration, alors que l'adoption des agents IA dans la gestion de code se généralise chez de nombreuses entreprises.

💬 Le détail qui tue : un simple mot, « Additionally », glissé dans un ticket public, a suffi à faire cracher à l'agent le contenu de deux dépôts privés. GitHub vendait ses gardes-fous comme du béton armé (sandbox, firewall, permissions en lecture seule) et ça n'a pas tenu deux minutes face à une injection de prompt basique. Dès qu'un agent IA cumule accès aux données privées, lecture de contenus venant d'inconnus et capacité à publier une réponse, la fuite n'est plus une hypothèse, c'est une question de temps.

Trois agents de codage IA ont laissé fuiter des secrets via une injection de prompt, un éditeur l'avait prédit

Un chercheur en sécurité de l'Université Johns Hopkins, Aonan Guan, accompagné de ses collègues Zhengyu Liu et Gavin Zhong, a publié la semaine dernière une divulgation technique intitulée "Comment and Control" démontrant qu'une simple injection de prompt dans le titre d'une pull request GitHub suffisait à compromettre trois agents de codage IA majeurs. L'attaque a forcé l'action Claude Code Security Review d'Anthropic à publier sa propre clé API en commentaire, et la même technique a fonctionné sur le Gemini CLI Action de Google ainsi que sur le Copilot Agent de GitHub (Microsoft), sans nécessiter aucune infrastructure externe. Les trois entreprises ont discrètement corrigé la faille : Anthropic l'a classée CVSS 9.4 Critique en versant une prime de 100 dollars, Google a payé 1 337 dollars, et GitHub a accordé 500 dollars via son programme Copilot Bounty. Aucune des trois n'avait publié de CVE officiel ni d'avis de sécurité public au moment de la divulgation. L'impact de cette vulnérabilité touche directement tous les dépôts GitHub utilisant le déclencheur pullrequesttarget, requis par la plupart des intégrations d'agents IA pour accéder aux secrets. Contrairement au déclencheur standard pull_request, ce mode injecte les secrets dans l'environnement d'exécution, exposant collaborateurs, champs de commentaires et flux de code automatisé à des acteurs malveillants. Merritt Baer, directrice de la sécurité chez Enkrypt AI et ancienne directrice adjointe de la sécurité chez AWS, résume l'enjeu sans détour : la protection doit se situer "à la frontière de l'action, pas à celle du modèle", c'est le runtime qui constitue le véritable périmètre d'exposition. Cette attaque illustre une surface de risque concrète pour toute organisation ayant intégré des agents IA dans ses pipelines de revue de code. Ce qui rend cet incident particulièrement révélateur, c'est que la fiche système d'Anthropic pour Claude Code Security Review indiquait explicitement que l'outil "n'est pas durci contre les injections de prompt", l'exploit n'a fait que confirmer ce qui était documenté. En comparaison, la fiche système d'OpenAI pour GPT-5.4 publie des évaluations d'injection au niveau du modèle mais ne documente pas la résistance au niveau du runtime ou de l'exécution des outils. Celle de Google pour Gemini 3.1 Pro, publiée en février, renvoie pour l'essentiel à une documentation plus ancienne et maintient son programme de red teaming entièrement interne, sans programme cyber externe. L'écart entre ce que les éditeurs documentent et ce qu'ils protègent réellement est désormais au coeur du débat sur la sécurité des agents IA déployés dans des environnements de développement sensibles.

💬 Anthropic a classé ça CVSS 9.4 et a payé 100 dollars de bounty. Cent dollars pour une fuite de clé API dans le titre d'une pull request, c'est le genre de disproportion qui dit tout sur comment ces outils ont été mis en prod. Le pire, c'est que c'était écrit noir sur blanc dans leur system card : "non durci contre les injections de prompt." Si tu utilises `pullrequesttarget` dans tes workflows GitHub avec un agent IA, va vérifier maintenant.

L'injection de prompts exploite les failles de conception des IA d'entreprise : agents, pipelines RAG et routeurs de modèles ciblés

L'injection de prompts s'est imposée comme la menace la plus critique pesant sur les systèmes d'intelligence artificielle en entreprise, selon plusieurs rapports convergents publiés entre 2025 et 2026. L'OWASP LLM Top 10 (édition 2025) la classe en première position pour la deuxième édition consécutive, reconnaissant l'incapacité persistante des grands modèles de langage à distinguer fiablement les instructions des données qu'ils traitent. Le rapport CrowdStrike Global Threat Report 2026, s'appuyant sur le suivi de plus de 280 groupes d'adversaires, documente des injections de prompts malveillants dans des outils d'IA générative légitimes au sein de plus de 90 organisations en 2025, utilisées pour voler des identifiants et des cryptomonnaies. Les attaquants pilotés par l'IA ont augmenté leur volume d'attaques de 89 % en un an, résumant la situation en une formule : "Les prompts sont le nouveau malware." Deux incidents concrets illustrent l'ampleur réelle du problème. En août 2024, des chercheurs de PromptArmor ont révélé une faille dans Slack AI permettant d'exfiltrer des données de canaux privés, y compris des clés API, simplement en plaçant une instruction malveillante dans un canal public. En juin 2025, Aim Security a divulgué EchoLeak (CVE-2025-32711, score CVSS 9.3), premier exploit zero-click documenté contre un système IA en production : en envoyant un seul email piégé, sans aucune interaction de l'utilisateur, un attaquant pouvait forcer Microsoft 365 Copilot à transmettre des fichiers internes vers un serveur externe. Les deux vulnérabilités ont depuis été corrigées. L'impact de ces attaques dépasse largement le cas isolé : elles exposent une faille structurelle dans la manière dont les entreprises déploient l'IA à grande échelle. Lorsqu'un modèle traite des instructions, résume des informations et déclenche des workflows automatisés, il devient difficile de distinguer une commande légitime d'une donnée corrompue. Les agents IA modernes peuvent envoyer des emails, modifier des infrastructures cloud, exécuter du code et interagir avec des systèmes internes, ce qui signifie qu'une seule instruction malveillante peut déclencher des actions aux conséquences réelles et durables. Le problème touche directement les équipes de sécurité, les DSI et les développeurs qui déploient ces systèmes sans protocoles de validation robustes. Les techniques d'injection ont considérablement évolué, ciblant désormais des architectures bien plus complexes que le simple chatbot. L'injection inter-modèles exploite le fait que la sortie corrompue d'un modèle sera traitée par d'autres modèles en aval, propageant ainsi la manipulation à travers toute la chaîne. L'empoisonnement de pipelines RAG consiste à publier des contenus malveillants (documentations, articles, READMEs GitHub) en espérant qu'ils soient ingérés par les systèmes de récupération d'information des entreprises. Le détournement d'agents et les attaques par débordement de contexte, utilisant des fenêtres de millions de tokens pour noyer les garde-fous dans un flot de données, complètent un arsenal en constante expansion. Face à cette réalité, la question n'est plus de savoir si une organisation sera ciblée, mais à quel moment ses pipelines IA seront compromis, et si elle aura mis en place les contrôles nécessaires pour le détecter.

Les défenseurs adoptent aussi l'injection de prompts

Des chercheurs de Tracebit ont annoncé lundi avoir découvert une méthode simple pour neutraliser les agents d'intelligence artificielle utilisés par des attaquants pour pirater des infrastructures cloud. Le principe consiste à placer des injections de prompt directement à côté des mots de passe, clés cryptographiques et autres secrets stockés sur AWS. Lorsqu'un agent LLM malveillant tente d'accéder à ces données sensibles, il tombe sur une instruction cachée qui lui ordonne d'effectuer une action interdite par ses propres garde-fous, les mécanismes de sécurité intégrés par les développeurs pour empêcher les IA de nuire. Résultat, le modèle s'arrête de lui-même, mettant fin à l'attaque en cours. Cette technique renverse une logique jusqu'ici à sens unique. Les injections de prompt sont traditionnellement l'arme favorite des attaquants: une commande habilement dissimulée dans un email, une invitation de calendrier ou un document suffit souvent à faire exécuter par un LLM des actions malveillantes, comme l'exfiltration de données confidentielles. Que des équipes de défense retournent cette même faille contre les assaillants marque un tournant. Pour les entreprises qui déploient des agents IA autonomes capables d'explorer des systèmes et de manipuler des identifiants, cela ouvre une piste de protection accessible et peu coûteuse, sans nécessiter de refonte des architectures de sécurité existantes. Cette découverte s'inscrit dans un contexte plus large où la sécurité des agents IA autonomes devient un enjeu majeur, à mesure que ces outils gagnent en autonomie et en capacité d'action sur des environnements sensibles comme le cloud. Les LLM utilisés à des fins offensives peuvent désormais scanner des systèmes, repérer des identifiants exposés et tenter de les exploiter sans supervision humaine constante. Face à cette menace grandissante, les chercheurs en sécurité explorent différentes pistes défensives, et cette méthode de piégeage par injection de prompt pourrait rapidement être adoptée par d'autres équipes de sécurité, voire intégrée nativement dans les outils de protection cloud, ouvrant la voie à une véritable course aux armements entre attaquants et défenseurs autour du contrôle des agents IA.

💬 Bonne nouvelle pour une fois côté défense: retourner l'injection de prompt contre l'attaquant, en planquant l'instruction d'arrêt à côté des secrets AWS, c'est malin et ça coûte trois fois rien à déployer. Reste que ça marche parce que l'attaquant utilise un agent avec des garde-fous actifs, un assaillant qui bricole son propre LLM sans ces limites passera au travers sans même s'en rendre compte. Le vrai signal ici, c'est que la sécurité cloud entre dans une course aux armements où le prompt lui-même devient un terrain de bataille, pas juste le code ou le réseau.