Des chercheurs en cybersécurité ont mis en lumière une faiblesse touchant Amazon Kiro injection, une série de scénarios où des fichiers fournis par un dépôt peuvent influencer le comportement d’un agent IA intégré à un IDE. L’objectif de l’attaquant : amener l’environnement de développement à transmettre des informations locales sensibles vers un point de collecte externe, sans que l’utilisateur ait l’impression d’avoir explicitement autorisé l’envoi.
Selon les informations publiées, il ne s’agit pas d’un bogue associé à un identifiant CVE. La vulnérabilité a été observée sur Kiro IDE 0.7.45 pour Windows, tandis que la version mentionnée comme la plus récente est 1.0.337. Un correctif a également été appliqué par Amazon dans Kiro IDE 0.8.140.
Une vulnérabilité centrée sur l’agent IA de Kiro
Le mécanisme décrit repose sur ce que les chercheurs appellent une prompt injection appliquée à un contexte plus large que de simples messages. L’idée n’est pas seulement de tromper l’IA avec un prompt malveillant ; elle consiste à utiliser le contenu d’un dépôt contrôlé par un attaquant pour orienter l’agent, puis déclencher des opérations sensibles au sein de l’IDE.
Un chercheur, Fergal Glynn, explique dans son rapport que le problème permet à des contenus issus d’un dépôt contrôlé par l’attaquant de modifier le comportement de l’agent et, in fine, de transmettre des informations locales sensibles vers un endpoint externe.
Ce qui rend la situation particulièrement préoccupante, c’est que l’utilisateur n’aurait pas nécessairement à soumettre un prompt explicitement malveillant, ni même à faire référence directement au contenu contrôlé par l’attaquant. Une fois le projet préparé et ouvert, l’envoi d’un message déclenche un flux vulnérable.
Comment Kiro Powers renforce le risque
Les chercheurs relient la vulnérabilité à la façon dont Kiro Powers enrichit l’environnement de l’agent. Au-delà des “compétences”, Kiro Powers regroupe des éléments tels que :
- des configurations de serveurs au format Model Context Protocol (MCP) ;
- des fichiers d’orientation (dont le nom est indiqué comme POWER.md) ;
- des hooks ;
- des connaissances contextuelles persistantes.
Le fichier d’orientation, présenté comme une sorte de manuel d’onboarding, fournit un contexte durable. Il précise notamment quels outils MCP sont disponibles et à quel moment l’agent doit les utiliser.
Dans ce cadre, si le contenu du projet malveillant parvient à être interprété comme une instruction, il peut influencer des opérations ultérieures jugées sensibles, puis détourner le fonctionnement de l’IDE pour créer une activité réseau non souhaitée.
Conditions d’exploitation : deux actions côté utilisateur
Selon Mindguard, l’exploitation nécessite deux actions de l’utilisateur. D’abord, l’utilisateur doit ouvrir un projet malveillant via un fichier workspace, en utilisant un chemin précis :
- ouvrir le projet via un workspace file ;
- passer par File → Open Workspace From File ;
- éviter l’ouverture directe du dossier.
Ensuite, une fois le projet chargé, l’utilisateur doit envoyer un message à l’agent.
Autre point important : les informations indiquent que la reproductibilité concerne aussi bien des workspaces confiés (“trusted”) que non confiés (“untrusted”). La difficulté d’exploitation est estimée comme faible.
Exfiltration sans demande explicite
Une fois les conditions réunies, des données du workspace peuvent être exfiltrées. Les chercheurs précisent que cela peut se produire sans que l’utilisateur ait explicitement demandé à Kiro d’accéder ou de transmettre ces informations.
Mindguard décrit un échec de frontière de confiance qui traverse l’enchaînement complet :
- le contenu contrôlé par le dépôt influence l’agent ;
- l’agent lit des informations locales sensibles ;
- l’agent écrit ces informations dans une configuration de l’IDE liée à la sécurité ;
- une fonctionnalité ultérieure de l’IDE transforme cette configuration modifiée en activité réseau.
Autrement dit, la chaîne ne dépend pas uniquement d’un message ; elle dépend du couplage entre interprétation du contenu et actions applicatives, avec des outils et une configuration qui peuvent être détournés.
Pourquoi ce type de faille se multiplie
Les conclusions s’inscrivent dans un contexte plus large : à mesure que les environnements de développement basés sur l’IA rapprochent interprétation et exécution dans un même flux, des fichiers de dépôt peuvent servir à fournir du contexte à un modèle. Ensuite, l’agent peut lire des fichiers, appeler des outils et activer des fonctionnalités de l’application, ce qui augmente le risque de ruptures de confiance.
Le constat est clair : lorsque l’IA se voit confier la capacité de naviguer dans l’état d’une application (outils, configuration, ressources externes), la surface d’attaque ne ressemble plus à celle des logiciels classiques.
Correctif et versions à surveiller
Après la divulgation responsable, Amazon a implémenté une correction dans Kiro IDE 0.8.140. Pour les équipes qui utilisent l’IDE, la mesure la plus directe consiste à mettre à jour vers une version corrigée et à vérifier que la déploiement atteint bien l’intervalle sécurisé.
Les informations publiées situent l’affectation sur une version antérieure (0.7.45) et mentionnent une version plus récente (1.0.337) comme référence. Pour autant, la recommandation reste de s’appuyer sur le numéro de version associé au correctif annoncé.
Un précédent lié aux fichiers d’orientation
La vulnérabilité décrite n’est pas isolée. Les chercheurs rappellent qu’un bug antérieur, également mis en avant par Mindguard, concernait la manière dont des directives dans un fichier d’orientation pouvaient amener des informations locales à être incorporées dans une requête en Markdown image, puis transmises à un serveur externe.
Le principe illustré est le suivant : en façonnant soigneusement le fichier d’orientation, un attaquant peut pousser l’IA à lire un fichier local puis à le rendre sous forme d’image Markdown, ce qui aboutit à l’envoi de données potentiellement sensibles vers l’extérieur.
Des exemples qui montrent l’ampleur du problème côté IA
Les informations fournies replacent cette découverte parmi plusieurs autres événements de sécurité touchant des outils d’IA et des interfaces de type “CLI”. Les chercheurs citent notamment des cas où des chaînes d’attaque exploitent la prompt injection, des manques de sandbox, ou des détournements de dépendances et de confiance dans l’environnement.
Sans dresser une liste exhaustive des détails techniques de chaque incident, la tendance générale est la suivante : lorsque des agents IA ont la capacité d’interagir avec des outils, d’écrire des fichiers ou d’initier des appels réseau, le risque de défaillance de frontière de confiance augmente.
Ce que les utilisateurs et équipes peuvent faire dès maintenant
En attendant que tous les postes soient à jour, quelques réflexes pratiques peuvent limiter l’exposition :
- Mettre à jour Kiro vers une version corrigée annoncée après divulgation responsable.
- Limiter l’ouverture de workspaces non vérifiés, surtout via des méthodes précises comme Open Workspace From File.
- Être attentif aux projets provenant de sources externes et aux comportements inattendus lors de l’envoi de messages à l’agent.
- Renforcer la vigilance autour des fichiers de pilotage et configurations que l’IDE pourrait interpréter (comme les fichiers d’orientation).
Enfin, les organisations peuvent aussi s’appuyer sur des contrôles complémentaires (politiques d’accès, durcissement, supervision) pour réduire l’impact potentiel d’un incident, même si la source précise du déclencheur se situe dans la logique agent + outils.
Conclusion : un risque d’exfiltration qui dépasse un seul IDE
La découverte autour de Amazon Kiro injection illustre un défi plus vaste : lorsque des environnements de développement IA combinent interprétation et exécution, le contenu d’un dépôt peut devenir un vecteur capable d’orienter des opérations sensibles. Dans le scénario décrit, des données locales peuvent être transmises à un endpoint externe après l’ouverture d’un workspace malveillant et l’envoi d’un message.
Le point positif, c’est l’existence d’un correctif annoncé dans Kiro IDE 0.8.140. La priorité, pour les utilisateurs comme pour les équipes sécurité, consiste à mettre à jour et à adopter des pratiques d’ouverture et d’usage plus prudentes des projets non maîtrisés.
Source: https://thehackernews.com/2026/08/amazon-kiro-prompt-injection-can.html
