Des chercheurs en cybersécurité ont dévoilé de nouvelles méthodes pour exfiltrer des données sensibles des environnements d'exécution de code d'intelligence artificielle (IA), en utilisant des requêtes de système de noms de domaine (DNS). Ces découvertes, ainsi que des divulgations distinctes concernant **LangSmith** et **SGLang**, soulignent le besoin croissant de mesures de sécurité robustes dans l'infrastructure de l'IA.  ### Vulnérabilité de l'interpréteur de code Amazon Bedrock AgentCore Un rapport de **BeyondTrust**, publié cette semaine, détaille comment le mode sandbox de **l'interpréteur de code Amazon Bedrock AgentCore** permet les requêtes DNS sortantes, permettant potentiellement aux attaquants d'établir des shells interactifs et de contourner l'isolation réseau. Ce problème, actuellement sans identifiant **CVE**, s'est vu attribuer un score CVSS de 7,5 sur 10,0. **L'interpréteur de code Amazon Bedrock AgentCore**, lancé en août 2025, est conçu pour permettre aux agents IA d'exécuter du code en toute sécurité dans des environnements sandbox isolés, empêchant les charges de travail agentiques d'accéder aux systèmes externes. Selon **Kinnaird McQuade**, architecte de sécurité en chef chez **BeyondTrust**, le fait que le service autorise les requêtes DNS malgré une configuration "sans accès réseau" pourrait permettre "aux acteurs malveillants d'établir des canaux de commande et de contrôle et d'exfiltrer des données via DNS dans certains scénarios, contournant ainsi les contrôles d'isolation réseau attendus." Dans une attaque de preuve de concept, les chercheurs ont démontré comment un acteur malveillant pourrait exploiter ce comportement pour établir un canal de communication bidirectionnel via des requêtes et des réponses DNS. Cela pourrait conduire à l'obtention d'un shell inversé interactif, à l'exfiltration d'informations sensibles via des requêtes DNS (en supposant que le rôle IAM ait les permissions nécessaires pour accéder aux ressources **AWS** comme les buckets **S3**), et à l'exécution de commandes. De plus, le canal de communication DNS peut être exploité pour livrer des **payloads** supplémentaires à l'interpréteur de code, l'incitant à interroger un serveur de commande et de contrôle (C2) DNS pour les commandes stockées dans les enregistrements A DNS, à les exécuter et à renvoyer les résultats via des requêtes de sous-domaines DNS. Les chercheurs ont souligné que des rôles IAM mal configurés pourraient exacerber le problème. Un rôle surprivilégié attribué au service pourrait lui accorder des permissions trop larges pour accéder à des données sensibles. "Cette recherche démontre comment la résolution DNS peut compromettre les garanties d'isolation réseau des interpréteurs de code sandboxés", a déclaré **BeyondTrust**. "En utilisant cette méthode, les attaquants auraient pu exfiltrer des données sensibles des ressources AWS accessibles via le rôle IAM de l'interpréteur de code, causant potentiellement des temps d'arrêt, des violations de données d'informations client sensibles, ou des infrastructures supprimées."  Suite à une divulgation responsable en septembre 2025, **Amazon** a classé ce comportement comme une fonctionnalité intentionnelle plutôt qu'un défaut. Ils recommandent d'utiliser le mode VPC au lieu du mode sandbox pour une isolation réseau complète et suggèrent d'employer un pare-feu DNS pour filtrer le trafic DNS sortant. **Jason Soroko**, chercheur principal chez **Sectigo**, conseille : "Pour protéger les charges de travail sensibles, les administrateurs doivent inventorier toutes les instances actives de l'interpréteur de code AgentCore et migrer immédiatement celles qui traitent des données critiques du mode Sandbox vers le mode VPC." Il a ajouté : "Opérer au sein d'un VPC fournit l'infrastructure nécessaire à une isolation réseau robuste, permettant aux équipes de mettre en œuvre des groupes de sécurité stricts, des ACL réseau et des pare-feux DNS Route53 Resolver pour surveiller et bloquer la résolution DNS non autorisée. Enfin, les équipes de sécurité doivent auditer rigoureusement les rôles IAM attachés à ces interpréteurs, en appliquant strictement le principe du moindre privilège pour limiter le rayon d'impact de toute compromission potentielle."  ### Vulnérabilité de prise de contrôle de compte LangSmith Dans l'actualité connexe, **Miggo Security** a divulgué une faille de sécurité de haute gravité dans **LangSmith** (**CVE-2026-25750**, score CVSS : 8,5) qui pourrait entraîner le vol de jetons et la prise de contrôle de compte. Ce problème, affectant les déploiements auto-hébergés et cloud, a été corrigé dans la version 0.12.71 de **LangSmith**, publiée en décembre 2025. La vulnérabilité découle d'un manque de validation sur le paramètre baseUrl, permettant une injection de paramètre d'URL. Un attaquant pourrait l'exploiter en incitant un utilisateur à cliquer sur un lien spécialement conçu, entraînant le vol de son jeton bearer, de son ID utilisateur et de son ID d'espace de travail. Exemples de liens : * Cloud - smith.langchain[.]com/studio/?baseUrl=https://attacker-server.com * Auto-hébergé - <domaine_LangSmith_du_client>/studio/?baseUrl=https://attacker-server.com Une exploitation réussie pourrait accorder un accès non autorisé à l'historique des traces de l'IA, exposant potentiellement des requêtes SQL internes, des enregistrements clients CRM, ou du code source propriétaire en examinant les appels d'outils. **Liad Eliyahu** et **Eliana Vuijsje**, chercheurs chez **Miggo**, ont déclaré : "Un utilisateur LangSmith connecté pourrait être compromis simplement en accédant à un site contrôlé par un attaquant ou en cliquant sur un lien malveillant."  Ils ont ajouté : "Cette vulnérabilité rappelle que les plateformes d'observabilité de l'IA sont désormais une infrastructure critique. Comme ces outils privilégient la flexibilité des développeurs, ils contournent souvent involontairement les garde-fous de sécurité. Ce risque est amplifié car, comme les logiciels "traditionnels", les agents IA ont un accès profond aux sources de données internes et aux services tiers." ### Failles d'unsafe pickle deserialization dans SGLang Enfin, des vulnérabilités ont été identifiées dans **SGLang**, un framework open-source populaire pour le service de grands modèles linguistiques et de modèles d'IA multimodaux. Une exploitation réussie pourrait entraîner une désérialisation pickle non sécurisée, potentiellement aboutissant à une exécution de code à distance. Ces failles, découvertes par **Igor Stepansky**, un chercheur en sécurité chez Orca, restent non corrigées. Les failles sont : * **CVE-2026-3059** (score CVSS : 9,8) - Une vulnérabilité d'exécution de code à distance non authentifiée via le broker ZeroMQ (alias ZMQ), qui désérialise des données non fiables en utilisant pickle.loads() sans authentification. Elle affecte le module de génération multimodale de SGLang. * **CVE-2026-3060** (score CVSS : 9,8) - Une vulnérabilité d'exécution de code à distance non authentifiée via le module de désagrégation, qui désérialise des données non fiables en utilisant pickle.loads() sans authentification. Elle affecte SGLang