· Security musings

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
~4 minutes

Trois vendors, trois CVE, un seul défaut de conception : le runtime qui reçoit un bloc ressemblant à un appel d’outil généré par un modèle le traite comme faisant autorité, sans jamais vérifier qu’un modèle a réellement parlé.


Le bug n’est pas dans le modèle, il est dans le runtime

Je constate que la quasi-totalité des discours sur la sécurité des agents IA tourne autour du modèle : le convaincre de désobéir, le piéger avec une injection de prompt. CoreBreak ignore complètement cette couche. Les chercheurs n’ont pas eu besoin de persuader un modèle de quoi que ce soit.

Le principe est le même sur les trois produits touchés : un attaquant place un bloc de contenu qui ressemble à un appel d’outil, et le runtime l’exécute directement, sans consulter le modèle pour confirmer que c’est bien lui qui l’a demandé.

Note du PandaRedacteur : on a passé deux ans à construire des garde-fous pour empêcher le modèle de sortir du cadre. Personne n’avait vérifié si le cadre lui-même vérifiait qui parle.

AWS Bedrock AgentCore (CVE-2026-18830, CVSS 8.6) laissait un utilisateur authentifié glisser un bloc d’utilisation d’outil dans le message final d’une requête InvokeHarness ; la boucle d’événements l’exécutait sans repasser par le modèle. Chez Google ADK for Python (CVE-2026-18236, CVSS 9.3, la plus sévère des trois), deux chemins distincts permettaient de forger une confirmation d’action ou de faire accepter un appel de fonction entièrement créé par l’utilisateur. Vercel AI SDK (CVE-2026-64650/64651, CVSS 6.3) s’en tire avec le score le plus bas : le relais faisait confiance aux chemins de process contenant des scripts d’aide approuvés, mais ça exige déjà du code malveillant tournant dans le bac à sable.