Que s'est-il passé
La Cloud Security Alliance a publié une note de recherche le 6 août 2026 décrivant CoreBreak, un ensemble de quatre CVE dans les cadres d'agent AWS, Google et Vercel dans lesquels la couche de répartition d'outils a exécuté un appel d'outil sans vérifier qu'un modèle de langage l'avait réellement produit. Tous les quatre ont des correctifs de fournisseur.
L'AI Safety Initiative de la Cloud Security Alliance a publié une note de recherche le 6 août 2026 décrivant un modèle de vulnérabilité multiplateforme que les chercheurs ont nommé CoreBreak. Selon la note, les chercheurs en sécurité Hedi Ingber et Aviyam Ivgi, co-fondateurs de la société de sécurité Stealth, ont présenté des résultats au Black Hat USA 2026 montrant que les couches d'exécution d'outils de Amazon Bedrock AgentCore, le kit de développement d'agent (ADK) de Google pour Python et les packages de harnais distribués avec le SDK AI de Vercel pourraient chacun être induits. pour exécuter un outil sans qu'un changement de modèle légitime ne se produise. Parce que le modèle linguistique n’a jamais été invoqué, affirme la note, les garde-fous construits autour du modèle n’ont eu aucune décision dans laquelle intervenir.
Les frameworks d'agents de ce type partagent une structure commune. Une couche d'orchestration regroupe la demande de l'utilisateur, l'invite système, l'historique des conversations et un catalogue d'outils disponibles, l'envoie à un modèle de langage et attend que le modèle renvoie une instruction structurée nommant un outil et ses arguments. Le SDK distribue ensuite la fonction, le script ou l'appel d'API correspondant et renvoie le résultat dans la conversation. CoreBreak cible la dernière étape : selon la note, la logique de répartition dans chacun des trois produits traitait les données qui ressemblaient simplement à un appel d'outil généré par un modèle comme faisant autorité, sans vérifier d'où elles venaient.
La note répertorie quatre identifiants CVE avec des chemins d'exploitation distincts, citant les bulletins des fournisseurs et les entrées de la base de données nationale sur les vulnérabilités. AWS a attribué CVE-2026-18830 (CVSS v4.0 8.6, High) à la faille du faisceau Bedrock AgentCore, où un appelant distant authentifié pouvait placer un bloc de contenu d'utilisation d'un outil directement dans le message final d'une requête API InvokeHarness. Google a attribué CVE-2026-18236 (9.3, Critique) à une faille ADK dans laquelle un attaquant capable d'injecter des événements dans l'historique de session pouvait falsifier une confirmation d'approbation humaine, car le processeur de confirmation ne vérifiait pas que l'outil cible appartenait à l'agent d'exécution, qu'il nécessitait réellement une confirmation ou que son nom et ses arguments correspondaient à l'appel enregistré d'origine. @ai-sdk/harness-codex et @ai-sdk/harness-opencode de Vercel ont reçu CVE-2026-64650 et CVE-2026-64651 (6.3, Medium chacun), où un code malveillant déjà exécuté dans un bac à sable Linux pouvait satisfaire à une vérification du chemin de processus qui faisait confiance à tout processus dont la ligne de commande contenait le chemin d'un script d'assistance approuvé.
Des correctifs sont disponibles, mais la charge diffère selon le modèle de déploiement. La note indique que le correctif de AWS pour l'API Bedrock AgentCore InvokeHarness entièrement gérée a été déployé automatiquement avant le 31 juillet 2026 et n'a nécessité aucune action du client, bien qu'elle conseille toujours de confirmer la couverture pour une région et une configuration données. Le correctif de Google livré dans ADK pour Python version 2.5.0 le 16 juillet 2026, et les correctifs de Vercel livrés dans harnais-codex 1.0.29 et harnais-opencode 1.0.28 le 10 juillet 2026 — mises à jour de package que les opérateurs auto-hébergés doivent appliquer eux-mêmes. La note présente CoreBreak comme distinct de l'injection rapide : l'injection rapide tente de manipuler le jugement du modèle, tandis que CoreBreak contourne la question de savoir si le modèle a exercé un jugement.
Détails de la source: labs.cloudsecurityalliance.org ↗
Pourquoi c'est important
Les filtres de contenu, les invites système, la formation aux refus et les portes d'approbation humaine supposent tous que le modèle est la partie qui décide si un outil fonctionne. Si la couche de répartition accepte tout ce qui ressemble à l'appel d'un outil de modèle, ces contrôles sont contournés plutôt que vaincus - et les équipes de surveillance des journaux inspectent normalement ne sont jamais créées.
La plupart des contrôles d’entreprise pour l’IA agentique reposent sur ou autour du modèle. Les invites du système restreignent les actions sensibles, les filtres de contenu notent les entrées et les sorties, la formation aux refus est intégrée aux pondérations du modèle et les étapes de confirmation humaine permettent d'accéder aux outils à haut risque. Chacun de ces contrôles suppose que le modèle est la partie qui décide si un outil fonctionne. Si une couche de répartition exécute une charge utile correctement formée, ces investissements n'offrent que peu de protection préventive, non pas parce qu'ils ont été mal conçus, mais parce que les attaques tournent autour de l'endroit où elles opèrent. Il s’agit là d’un problème différent du garde-fou qui peut être contourné.
Les capacités spécifiques derrière ces couches de répartition sont ce qui donne du poids aux conclusions. La note indique que les failles Vercel pourraient atteindre les outils exposés à l'hôte, notamment les recherches de secrets, les opérations de déploiement et les appels d'API cloud. La faille Google est encore plus pointue : elle permettait à de fausses confirmations d'atteindre des outils délibérément placés derrière l'approbation humaine, qui est la réserve des organismes de contrôle pour les actions jugées trop conséquentes pour être automatisées. Un contournement qui neutralise spécifiquement l’étape de l’humain dans la boucle sape les mesures d’atténuation citées par de nombreuses équipes pour justifier une plus grande autonomie des agents.
L’histoire des correctifs illustre également une asymétrie qui se reproduira à mesure que les outils d’agent se répandront. Les clients du service AWS entièrement géré ont été corrigés sans rien faire. Les équipes exécutant l'ADK de Google ou les packages de harnais de Vercel dans leurs propres environnements doivent remarquer l'avis, mettre à jour la dépendance et redéployer – et les mises à jour des dépendances dans les piles de production sont régulièrement décalées de plusieurs semaines ou mois. La même lacune de conception sous-jacente a donc une fenêtre d’exposition pratique très différente selon qu’une organisation consomme l’infrastructure d’agent en tant que service ou la vend dans sa propre base de code.
Il existe également un déficit de détection. La note observe que la surveillance de la sécurité des systèmes agents s'est généralement concentrée sur les entrées et sorties du modèle : journalisation des invites, signalement des achèvements suspects, examen des outils choisis par le modèle. Lorsqu'un outil s'exécute sans que le modèle ne soit exécuté, aucun de ces artefacts n'existe pour être enregistré. Plusieurs choses importantes restent inconnues : la note ne rapporte aucune preuve d'exploitation dans la nature, ne donne aucune estimation du nombre de déploiements affectés et ne décrit pas le code de validation de principe. CSA affirme franchement que deux divulgations provenant de quatre fournisseurs ne prouvent pas une tendance à l'échelle du secteur et que le gradient de gravité observé constitue un point de données plutôt qu'une règle de notation.
Mécanisme interactif : comment cela fonctionne réellement
Explorez de manière interactive la technologie sous-jacente à ce développement.
crm_get_transaction(id='4092').What most distinguishes an AI agent from a basic chatbot?
Que regarder ensuite
Si les opérateurs auto-hébergés appliquent réellement les mises à jour des packages Google et Vercel, si des lacunes de provenance similaires apparaissent dans d'autres cadres d'agents, si une exploitation sauvage est signalée et si les fournisseurs optent pour des jetons d'autorisation signés et liés à la session pour l'exécution des outils.
La question la plus concrète à court terme est celle de l’adoption des correctifs. Le correctif géré de AWS est décrit comme déjà déployé, mais ADK 2.5.0 et les deux versions du faisceau Vercel n'aident que les opérateurs qui les installent. Surveillez les signaux en aval : les taux d'adoption du registre des packages, les forks fournis par les fournisseurs qui n'extraient jamais la mise à jour et les images de plate-forme interne qui épinglent les anciennes versions. La note recommande également une vérification rétrospective : examiner les journaux pour détecter les appels d'outils qui ne peuvent pas être liés à un achèvement de modèle correspondant et bien formé dans l'enregistrement de session. La question de savoir si les organisations disposent de la télémétrie au niveau de la couche de répartition pour effectuer cette vérification n'est en soi pas résolue.
La deuxième question est la portée. CoreBreak couvre trois produits, mais le modèle décrit – faire confiance à la forme d'une charge utile ou à la ligne de commande d'un processus comme preuve de l'autorisation du modèle – ne leur est pas spécifique. Tout framework doté de la même structure SDK-modèle-outil pourrait comporter un écart comparable. Surveillez les autres avis émis par d'autres responsables du framework d'agents et vérifiez si les chercheurs publient des détails techniques plus complets après la présentation de Black Hat. Des cas confirmés supplémentaires renforceraient l'argument du CSA selon lequel il s'agit d'un modèle structurel plutôt que de trois bogues fortuits.
Troisièmement, observez la réponse architecturale. La recommandation de CSA est d'exiger une preuve cryptographique qu'un appel d'outil provient d'un véritable achèvement de modèle (un jeton unique signé, lié à une session) plutôt que de déduire une autorisation à partir de la structure du message ou de l'identité du processus. Le fait que les principaux fournisseurs adoptent ce modèle et s'il devient quelque chose que les acheteurs peuvent demander et vérifier lors de l'approvisionnement déterminera si cette divulgation modifie les conceptions ou ne produit que des correctifs. La logique de traitement de confirmation qui valide la propriété de l'outil, les exigences de confirmation et l'intégrité des arguments par rapport à l'appel enregistré d'origine est la version plus étroite du même correctif.
Enfin, surveillez les pistes de gouvernance et de renseignement sur les menaces. CSA souligne son cadre de modélisation des menaces MAESTRO et AI Controls Matrix v1.1 comme des endroits où les évaluations du contrôle d'exécution et de la gestion des privilèges devraient désormais couvrir explicitement la répartition des outils, et relie CoreBreak à ses recherches antérieures GuardFall sur les contournements des garde-corps au niveau de l'enveloppe. Il convient également de surveiller : si les entrées NVD ou les scores CVSS sont révisés, si les fournisseurs publient des détails post-incident au-delà des bulletins initiaux et si une exploitation confirmée émerge. Aucun des quatre CVE ne publie actuellement de rapport public sur les abus dans la nature dans les documents cités par le CSA, et l'absence de tels rapports n'est pas la même chose que l'absence d'activité.