veilletech.fr
28 août Feed du jour
#02 IA Article

Kiro : un dépôt piégé fait fuiter vos secrets

Ouvrir un dépôt dans un IDE agentique, c'est exécuter du code.

Un fichier de pilotage placé dans un dépôt suffit à détourner l'agent d'Amazon Kiro et à lui faire écrire des données locales sensibles vers un point de sortie externe. Il n'y a ni consigne visible ni contournement du mode « untrusted » : ouvrir le workspace et envoyer un message quelconque suffit.

3 min de lecturevidéo 1:15
Partager
Sommaire4 sections
  1. Ce qui se passe
  2. Pourquoi ça compte
  3. Ce que ça change
  4. À retenir

Ce qui se passe

Mindgard a publié le détail d'une exfiltration de données dans Amazon Kiro, l'IDE agentique d'AWS. Le défaut, sans identifiant CVE, a été démontré sur la version 0.7.45 sous Windows et corrigé par Amazon en 0.8.140 ; la version courante de l'IDE est la 1.0.337.

Le vecteur, ce sont les Kiro Powers : des paquets qui vont plus loin que de simples skills en rassemblant une configuration de serveurs MCP, des steering files (POWER.md), des hooks et du contexte métier. Le steering file tient lieu de manuel d'accueil — il dit à l'agent quels outils MCP existent et quand s'en servir. Un dépôt hostile en fournit un.

Deux gestes suffisent, et aucun n'est suspect :

  1. ouvrir le projet par File → Open Workspace From File, et non par l'ouverture directe du dossier ;
  2. envoyer un message à l'agent. N'importe lequel.

L'utilisateur n'a pas à écrire de prompt malveillant ni même à mentionner le contenu piégé. La difficulté d'exploitation est jugée faible, et le scénario se reproduit aussi bien sur un workspace marqué de confiance que sur un workspace non fiable.

Pourquoi ça compte

La frontière de confiance ne cède pas à un endroit précis : elle cède sur toute la séquence. Le contenu du dépôt devient une instruction, l'instruction pilote une lecture locale, la lecture atterrit dans une configuration de l'éditeur, et c'est une fonction ultérieure de l'IDE qui transforme cette configuration en trafic réseau.

Serveur externeConfig de l'IDEAgent KiroDépôt piégéServeur externeConfig de l'IDEAgent KiroDépôt piégéAucune étape ne demande d'approbationsteering file lu à l'ouverturedu workspacemessage utilisateur→ l'agent appliquele « manuel »écrit les données locales luesdans la configurationune capacité de l'IDE émet larequête

Aucun maillon n'est en soi une faille : lire un fichier du projet, écrire une configuration, appeler un service sont des opérations normales. C'est leur mise bout à bout qui déplace la donnée.

Ce que ça change

Ce n'est pas le premier incident sur cet IDE, ni le seul outil concerné. En juin 2026, Amazon corrigeait CVE-2026-10591 (CVSS 8.8), un contrôle d'accès insuffisant qui permettait d'écrire dans des chemins auto-exécutés comme .vscode/tasks.json ou ~/.kiro/settings/mcp.json. Intezer avait montré qu'une page web lue par Kiro pouvait lui faire réécrire sa propre configuration MCP.

Le même schéma — interprétation et exécution dans le même flux — a produit ces derniers mois :

Outil Identifiant Nature
Claude Code CVE-2026-35603 dossier C:\ProgramData\<app> de confiance sous Windows
Claude Code CVE-2026-25725 (7,7) évasion de bac à sable via .claude/settings.json
VS Code (« Envade ») CVE-2026-41613 (8,8) dialogue d'installation MCP, exécution en un clic
NVIDIA NemoClaw CVE-2026-65105 (8,1) prise de contrôle du serveur Ollama local

La règle pratique qui en découle ne dépend d'aucune version : ouvrir un dépôt inconnu dans un IDE agentique équivaut à exécuter un binaire inconnu. Le mode « untrusted » ne protège pas ici, et l'absence de demande d'approbation est le comportement attendu, pas un bug.

Source : The Hacker News, Amazon Kiro Prompt Injection Can Exfiltrate Sensitive Data Through Kiro Powers · rapport : Mindgard