Une faille dans les agents a été mise en évidence dans des composants d’infrastructure utilisés pour piloter des agents IA. Dans plusieurs scénarios, des instructions non fiables (ou forgées) ont pu atteindre la couche d’exécution et déclencher des outils sans qu’un « tour » du modèle n’ait validé l’intention. Résultat : certains contrôles basés sur le modèle — comme les prompts système, les filtres de contenu et les garde-fous — n’ont simplement pas eu le temps d’intervenir.
Les chercheurs à l’origine de la découverte ont présenté ce schéma à Black Hat USA 2026, et plusieurs éditeurs ont depuis publié des corrections. Bien que les problèmes ne soient pas identiques, ils convergent vers un point commun : l’exécution d’un outil ne devrait jamais être « autorisée » uniquement sur la forme de la donnée qui arrive à la couche de dispatch.
Pourquoi l’exécution d’outils peut contourner le modèle
Dans un flux d’agent « normal », le SDK envoie au modèle la requête de l’utilisateur, le prompt système, l’historique de conversation et la liste des outils disponibles. Ensuite, le modèle décide s’il faut appeler un outil, et renvoie une instruction structurée (nom de l’outil et arguments). Le SDK exécute alors cet appel.
Dans les chemins vulnérables décrits, une vérification de provenance manquait entre l’instruction supposée issue du modèle et l’étape d’exécution. Autrement dit, le runtime recevait des données qui ressemblaient à un appel d’outil généré par le modèle, puis les traitait comme faisant autorité, sans exiger que l’étape modèle ait réellement eu lieu.
Dans plusieurs attaques, le modèle ne s’exécutait même pas. Cela implique que la sécurité « côté modèle » ne peut pas empêcher le déclenchement de l’outil : la décision a été court-circuitée en amont.
Trois écosystèmes touchés : AWS, Google et Vercel
Les faille dans les agents repérées ne concernent pas exactement la même condition d’attaque. Par exemple, les chercheurs indiquent que :
- AWS impliquait une requête distante authentifiée.
- Google nécessitait des événements contrôlés par l’attaquant dans la session, ou des appels de fonctions rédigés par l’utilisateur.
- Vercel reposait sur du code non fiable déjà en cours d’exécution dans un environnement sandbox Linux, avec un relais d’autorisation côté processus.
Malgré ces différences, le fil conducteur reste le même : lorsque l’autorisation d’exécution ne dépend pas réellement d’un événement modèle légitime, un attaquant peut essayer d’accéder à des chemins de dispatch ou de relay sans validation appropriée.
Correctif AWS : InvokeHarness et validation côté serveur
Pour AWS, la société a publié une correction associée à CVE-2026-18830 (score CVSS v4.0 : 8,6). Le bulletin décrit un souci de validation d’entrée dans un harness lié à Amazon Bedrock AgentCore.
Dans le scénario concerné, un utilisateur distant authentifié pouvait placer un bloc de contenu « ToolUse » dans le message final d’une requête InvokeHarness. Ensuite, la boucle d’événements pouvait exécuter directement l’outil demandé, sans passer par une étape modèle qui aurait normalement autorisé l’appel.
AWS a indiqué que la vulnérabilité affectait le service managé avant le 31 juillet 2026. La mitigation a été appliquée côté serveur : elle rejette automatiquement les blocs ToolUse fournis par l’appelant avant qu’ils n’atteignent la boucle d’événements. Selon AWS, il n’y a donc pas d’action requise côté client pour le service managé.
Le cas Strands : un raccourci de branche non couvert pour tous
Les chercheurs précisent toutefois que le correctif du service managé ne couvre pas un chemin similaire dans le code Python open source Strands, qui sert de base au harness. Ils indiquent que le fichier event_loop.py contient une branche qui, si une vérification indique que le dernier message contient une entrée « ToolUse », peut définir directement la raison d’arrêt à « tool_use » et sélectionner le dernier message, sans exécuter le modèle.
Cette logique implique que, dans certaines applications Strands, un agencement particulier de l’historique ou la possibilité de soumettre des messages structurés non fiables pourrait permettre d’atteindre l’exécution d’outil sans tour modèle.
Les chercheurs notent également que l’exposition dépend de la manière dont l’application gère les entrées : si un appelant non fiable peut influencer les messages structurés, ou modifier l’historique stocké de façon à ce que la boucle d’événements consomme une portion donnée, le risque augmente. AWS n’a pas publié de plage de versions distincte ou de notice CVE dédiée pour des déploiements Strands autonomes ; la réponse mentionnée par les chercheurs évoque plutôt une modification de la documentation et le fait que cela relève de la responsabilité du client dans le modèle de responsabilité partagée.
Correctif Google : ADK Python et deux chemins distincts
Chez Google, deux volets de correction ont été associés à Agent Development Kit (ADK) pour Python. Le premier concerne CVE-2026-18236 (score CVSS v4.0 : 9,3), touchant les versions antérieures à 2.5.0.
ADK permet de marquer un outil « sensible » comme nécessitant une confirmation humaine : l’appel est alors retenu jusqu’à approbation. Dans la voie vulnérable, un attaquant capable de manipuler ou d’injecter des événements dans l’historique de session pouvait forger une approbation et ainsi déclencher un outil sans autorisation légitime.
Le correctif introduit des vérifications supplémentaires : il s’assure que l’outil correspond à celui attendu par l’agent, que l’appel nécessitait réellement une confirmation, et que le nom et les arguments correspondent à ce qui a été enregistré dans la session. Les détails indiquent que le patch rend l’approbation liée au contexte exact de l’appel.
Le second correctif a également été livré dans ADK 2.5.0 (déployé le 16 juillet 2026). Cette fois, il s’agit d’un contournement dans un mode « reprenable » : des flux acceptaient des événements rédigés par l’utilisateur, contenant des parties de type function_call, pouvant être interprétées comme des instructions d’exécution d’outils déjà enregistrés.
Le correctif rejette désormais les appels de fonctions dans les messages fournis par l’utilisateur, afin d’éviter que l’on puisse bypass le rôle du modèle en exécutant directement des outils enregistrés.
Correctif Vercel : relais d’outils et autorisation plus stricte
Enfin, Vercel a corrigé des problèmes liés au harness d’outils pour ses agents de codage, notamment @ai-sdk/harness-codex et @ai-sdk/harness-opencode.
Les avis publics listent :
- CVE-2026-64650 pour @ai-sdk/harness-codex (version jusqu’à 1.0.28), score CVSS v4.0 : 6,3.
- CVE-2026-64651 pour @ai-sdk/harness-opencode (version jusqu’à 1.0.27), score CVSS v4.0 : 6,3.
Le cœur du souci tient au fait que le relais faisait confiance au chemin d’un processus via la ligne de commande contenant un repère associé à un script helper approuvé. L’idée d’origine était de réduire la surface d’attaque, mais les chercheurs montrent que du code malveillant déjà présent dans la sandbox Linux pouvait satisfaire cette vérification et déclencher des outils exposés côté hôte, y compris des opérations sensibles comme des recherches de secrets, des actions de déploiement ou des appels à des API cloud.
Pour exploiter ce type de faille dans les agents, il fallait un environnement Linux, une session active du harness avec au moins un outil fourni par l’hôte, et surtout du code non fiable déjà exécuté dans la sandbox (par exemple une dépendance malveillante, un script de build ou un hook de cycle de vie).
La correction : suppression du « fallback » et autorisation à usage unique
Vercel indique avoir retiré la voie de secours liée au chemin de processus. Désormais, le relais n’exécute une demande que si elle correspond exactement à une autorisation à usage unique, courte durée, associée à la nature précise de l’événement observé côté modèle (nom de l’outil et entrée observée dans l’événement).
Les chercheurs confirment via le registre npm que les versions corrigées ont été publiées le 10 juillet 2026, puis que des versions plus récentes étaient déjà disponibles au 5 août 2026.
Ils mentionnent également un correctif antérieur (lié à un PR fusionné le 10 juin 2026) qui durcissait la logique de rejouabilité des confirmations d’outils contre des approbations forgées côté client. Vercel décrit des contrôles basés sur une signature HMAC optionnelle et une revalidation des entrées d’outil avant la reprise d’exécution, dans ses notes de version d’AI SDK 7. Les chercheurs attribuent certaines idées à une autre équipe de recherche (décrite dans la source).
Ce que ces correctifs ont en commun
À la date de publication, les éléments publics ne prouvent pas clairement si ces voies d’attaque ont été exploitées en production avant les patches. Les chercheurs affirment avoir envoyé du code de démonstration aux éditeurs concernés, sans le publier publiquement.
Mais les remèdes convergent vers une même exigence d’architecture : la couche d’exécution doit vérifier que l’appel d’outil correspond à un événement modèle légitime. Aucune des corrections ne consiste simplement à « renforcer le modèle » ou à s’appuyer uniquement sur des prompts, puisque les scénarios décrits court-circuitent précisément ce moment où le modèle devrait agir.
Concrètement, les approches décrites se résument à :
- Vérifier la cohérence session + outil + arguments (par exemple côté Google pour les confirmations).
- Relier chaque exécution à une autorisation one-shot issue d’un événement modèle observé (côté Vercel).
- Rejeter en amont les blocs d’outils fournis par l’appelant avant qu’ils n’atteignent la boucle d’événements (côté AWS).
En filigrane, le principe est le même : la « forme » d’une donnée ne doit pas suffire à remplacer l’autorisation du modèle.
Bonnes pratiques : réduire le risque autour des outils
Au-delà des correctifs de versions, la source rappelle plusieurs pratiques de sécurité applicables aux intégrations d’agents. Elles ne remplacent pas les patches, mais elles limitent l’impact potentiel d’une mauvaise vérification.
- Mettez à jour les bibliothèques concernées : ADK Python vers 2.5.0 ou plus, et les harness Vercel vers les versions corrigées indiquées.
lorsqu’ils traversent une frontière externe (entrées de conversation, événements « reprenable », confirmations, blocs structurés). - Autorisez à l’instant d’exécution : l’appel doit être lié au nom exact de l’outil, aux arguments exacts, au contexte de session et à l’état d’autorisation produit par l’événement modèle.
- Limitez l’autorité héritée : donnez à chaque agent uniquement les outils et droits indispensables (rôles, identifiants, permissions d’écriture).
Enfin, il est important de noter que la source insiste sur un point : ce n’est pas un simple problème d’injection de prompt. Ici, le modèle ne reçoit parfois même pas de tour ; il n’y a donc pas de « modèle à tromper » au sens classique.
Conclusion
Cette série de corrections met en lumière une faille dans les agents où l’exécution d’outils peut se faire sans validation réelle par le modèle. AWS, Google et Vercel ont chacun publié des mesures adaptées à leur architecture : validation serveur, contrôles de cohérence en session, et autorisations à usage unique liées à un événement modèle observé.
Pour les équipes qui déploient des agents, le message clé est clair : l’autorisation doit être prouvée au moment d’exécution, et les composants doivent refuser toute entrée qui imiterait un appel de l’agent sans passer par le chemin modèle prévu.
Source: https://thehackernews.com/2026/08/aws-google-and-vercel-patch-agent-flaws.html
