Aller au contenu principal
7 000 serveurs Langflow sous attaque : LangGraph et LangChain présentent les mêmes failles
SécuritéVentureBeat AI1sem· 2 min de lecture

7 000 serveurs Langflow sous attaque : LangGraph et LangChain présentent les mêmes failles

Source originale ↗·

Sept mille serveurs Langflow sont actuellement ciblés par des attaquants exploitant une vulnérabilité critique dans ce framework de création d'agents IA. La faille, identifiée sous le code CVE-2026-5027 et notée 8,8 sur 10 selon l'échelle CVSS, réside dans l'endpoint POST /api/v2/files de Langflow : le nom de fichier transmis lors d'un upload est accepté sans aucun assainissement, permettant d'écrire un fichier n'importe où sur le serveur, par exemple une tâche planifiée dans /etc/cron.d/. Langflow activant par défaut la connexion automatique, aucune authentification n'est requise pour exploiter la faille. La chercheuse Caitlin Condon de VulnCheck a confirmé des exploitations actives le 9 juin 2026, avec des fichiers-tests déposés sur des machines victimes. Deux autres frameworks sont également touchés : Check Point Research a mis au jour dans LangGraph une chaîne partant d'une injection SQL dans le checkpointer SQLite (CVE-2025-67644, CVSS 7.3) pour aboutir à une exécution de code à distance via un décodeur msgpack vulnérable (CVE-2026-28277, CVSS 6.8), ainsi qu'un troisième vecteur sur le checkpointer Redis (CVE-2026-27022, CVSS 6.5). Cyera a par ailleurs documenté une traversée de chemin dans le chargeur de prompts de LangChain-core, permettant de lire des secrets stockés sur disque.

L'enjeu dépasse la simple mise à jour logicielle. Ces frameworks, LangGraph à lui seul dépasse 50 millions de téléchargements mensuels, sont devenus en quelques mois une infrastructure de production critique : ils stockent l'état d'exécution des agents, gèrent les uploads de fichiers, chargent des configurations de prompts et concentrent les credentials donnant accès aux bases de données, aux CRM et aux API internes. Une clé OpenAI compromise ou un token CRM exfiltré produit un rayon de destruction bien au-delà du seul serveur touché. Les outils de sécurité traditionnels, qu'il s'agisse de solutions réseau ou d'analyse de processus, n'ont pas été conçus pour surveiller un framework importé comme un périmètre à défendre, laissant précisément ces couches sans protection adéquate.

Ce qui est frappant dans ces trois incidents, c'est qu'ils partagent la même classe de bug : injection SQL et traversée de chemin, des vulnérabilités documentées depuis des décennies, réappliquées à des outils d'IA dont le déploiement a largement devancé la sécurisation. La course à l'adoption en production a créé une surface d'attaque vaste et peu contrôlée. Pour LangGraph, les correctifs sont disponibles immédiatement : langgraph-checkpoint-sqlite doit passer en version 3.0.1, langgraph en 1.0.10, et langgraph-checkpoint-redis en 1.0.2. Pour Langflow, la priorité est d'interdire toute exposition publique sans authentification forcée. La publication d'un proof-of-concept fonctionnel par Check Point pour LangGraph, combinée aux exploitations déjà constatées sur Langflow, laisse peu de marge aux équipes pour réagir.

Impact France/UE

Les développeurs et entreprises européens déployant LangFlow, LangGraph ou LangChain en production doivent appliquer les correctifs en urgence : des exploitations actives permettent d'exfiltrer credentials et secrets donnant accès aux bases de données, CRM et APIs internes.

💬 L'analyse de Mathieu

Honnêtement, ça va plus loin qu'une simple faille logicielle. Langflow, LangGraph et LangChain, autant que les 7 000 serveurs en question, sont devenus une infrastructure critique pour stocker des agents IA et des secrets d'accès. Une clé OpenAI ou un token CRM compromis, c'est la porte ouverte à une cascade de problèmes bien au-delà d'un simple serveur touché. Les outils de sécurité traditionnels ne sont pas faits pour surveiller ces frameworks importés comme des périmètres à défendre, c'est un problème. Et la course à l'adoption en production a créé une surface d'attaque immense et mal contrôlée. Les correctifs sont disponibles pour LangGraph, mais pour Langflow, c'est surtout urgent de blinder toute exposition publique sans authentification forcée. Avec des exploitations déjà constatées, les équipes ont peu de marge pour réagir.

Dans nos dossiers

Cet article vous a été utile ?

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

200 000 serveurs MCP exposent une faille d'exécution de commandes qu'Anthropic considère comme une fonctionnalité
1VentureBeat AI 

200 000 serveurs MCP exposent une faille d'exécution de commandes qu'Anthropic considère comme une fonctionnalité

Quatre chercheurs de la société OX Security ont révélé en avril 2026 une faille architecturale affectant environ 200 000 serveurs MCP (Model Context Protocol), le standard ouvert créé par Anthropic pour connecter les agents d'IA aux outils logiciels. Le transport STDIO, utilisé par défaut dans les SDK officiels Python, TypeScript, Java et Rust, exécute n'importe quelle commande système reçue sans aucune sanitisation ni frontière entre configuration et exécution. Les chercheurs Moshe Siman Tov Bustan, Mustafa Naamnih, Nir Zadok et Roni Bar ont scanné l'écosystème, identifié 7 000 serveurs publiquement accessibles avec STDIO actif, et extrapolé à 200 000 instances vulnérables au total. Ils ont confirmé l'exécution arbitraire de commandes sur six plateformes en production réelle. La divulgation a produit plus de 10 CVE notées "high" ou "critical" touchant LiteLLM, LangFlow, Flowise, Windsurf, LangChain-Chatchat, DocsGPT, GPT Researcher, Agent Zero et LettaAI, entre autres. Windsurf (CVE-2026-30615) s'est avéré exploitable en zéro clic via injection de prompt dans des fichiers de configuration locaux. Neuf des onze registries MCP testés ont accepté un paquet malveillant de démonstration sans aucune vérification de sécurité. L'impact est d'autant plus sérieux que la faille n'est pas un bug isolé dans un produit particulier, mais un défaut de conception propagé par le protocole lui-même à toute la chaîne de dépendance. Tout projet ayant fait confiance au SDK officiel a hérité du problème. Carter Rees, VP IA chez Reputation et membre de l'Utah AI Commission, juge que le cadre conceptuel doit changer radicalement : STDIO doit être traité comme un accès shell en production, avec blocage par défaut, liste d'autorisation stricte et sandbox, et non comme un connecteur banal. Kevin Curran, professeur de cybersécurité à l'Ulster University et membre senior de l'IEEE, parle d'un "écart choquant dans la sécurité de l'infrastructure IA fondamentale". Pour les équipes sécurité, la question pratique est immédiate : tout déploiement d'agent IA via STDIO est exposé, quelle que soit la qualité du code applicatif en aval. Anthropic a confirmé que ce comportement est intentionnel et a refusé de modifier le protocole, qualifiant le modèle d'exécution de STDIO de valeur par défaut sécurisée et renvoyant la responsabilité de la sanitisation aux développeurs. OX conteste cette position en soulignant qu'exiger de 200 000 développeurs une sanitisation correcte des entrées est précisément le problème structurel. La tension est techniquement légitime des deux côtés : sanitiser STDIO risque soit de casser le transport, soit de déplacer le vecteur d'attaque d'un niveau. Le protocole MCP a pourtant connu une adoption massive depuis sa création par Anthropic, son adoption par OpenAI en mars 2025 et par Google DeepMind, sa cession à la Linux Foundation en décembre 2025, et 150 millions de téléchargements. La question de la gouvernance de sécurité des standards ouverts d'IA devient ainsi aussi urgente que leur interopérabilité.

UELes équipes IA européennes déployant des agents via MCP/STDIO sont directement exposées à cette faille architecturale sans correctif disponible, Anthropic ayant refusé de modifier le protocole.

SécuritéActu
1 source
Quatre attaques sur la chaîne d'approvisionnement IA en 50 jours révèlent des failles dans les pipelines de déploiement
2VentureBeat AI 

Quatre attaques sur la chaîne d'approvisionnement IA en 50 jours révèlent des failles dans les pipelines de déploiement

En cinquante jours, quatre incidents de sécurité ont frappé les chaînes d'approvisionnement logicielle d'OpenAI, Anthropic et Meta, exposant un angle mort systémique dans l'écosystème IA. Le 11 mai 2026, un ver informatique baptisé Mini Shai-Hulud a publié 84 versions malveillantes de 42 packages npm de la bibliothèque TanStack en six minutes, en exploitant une mauvaise configuration de GitHub Actions, un empoisonnement du cache CI et l'extraction d'un token OIDC depuis la mémoire du runner. Ces packages portaient une provenance SLSA Build Level 3 valide car ils avaient été publiés depuis le dépôt officiel, via le bon workflow. Deux jours plus tard, OpenAI confirmait la compromission de deux appareils d'employés et l'exfiltration de secrets depuis ses dépôts internes, forçant la révocation de ses certificats macOS et une mise à jour obligatoire de tous les utilisateurs desktop avant le 12 juin 2026. En remontant à fin mars, on trouve deux autres incidents : un chercheur de BeyondTrust Phantom Labs, Tyler Jespersen, avait découvert que OpenAI Codex passait les noms de branches Git directement dans des commandes shell sans aucune validation, permettant l'injection de sous-commandes et le vol du token OAuth GitHub en clair. Simultanément, le groupe TeamPCP avait utilisé des identifiants volés au scanner de vulnérabilités Trivy d'Aqua Security pour publier deux versions empoisonnées du proxy LiteLLM sur PyPI, téléchargées près de 47 000 fois en quarante minutes avant quarantaine. Ce qui rend ces incidents particulièrement préoccupants, c'est leur portée transversale. L'attaque LiteLLM a atteint Mercor, une startup valorisée 10 milliards de dollars qui fournit des données d'entraînement à Meta, OpenAI et Anthropic : quatre téraoctets ont été exfiltrés, incluant des références à des méthodologies propriétaires de Meta. Le partenariat a été gelé immédiatement, une action collective a suivi dans les cinq jours. Aucune de ces attaques ne visait les modèles eux-mêmes, mais leurs dommages sont réels et mesurables. Le 31 mars, Anthropic avait de son côté exposé involontairement 513 000 lignes de TypeScript non obfusqué en livrant Claude Code version 2.1.88 avec un fichier source map de 59,8 Mo qui n'aurait jamais dû être inclus, révélant 44 feature flags internes, des prompts système et l'architecture d'orchestration multi-agents. Ces quatre incidents convergent vers un seul constat structurel : les pipelines de release, les hooks de dépendances, les runners CI et les gates de packaging ne sont couverts par aucun exercice de red team actuel dans l'industrie IA. Les évaluations AISI, les system cards et les audits de sécurité des modèles ignorent entièrement cette surface d'attaque. Quand un token OIDC légitimement émis suffit à publier 84 artefacts malveillants avec une provenance cryptographique valide, ou qu'une seule dépendance open source passe quarante minutes sur PyPI avec un effet blast radius cross-industriel, la robustesse du modèle sous-jacent devient hors-sujet. La pression monte pour que les fournisseurs IA intègrent des audits de sécurité de chaîne d'approvisionnement dans leurs questionnaires de conformité, au même titre que les évaluations de danger des modèles.

UELes organisations européennes déployant des outils IA via des dépendances open source (LiteLLM, TanStack) sont directement exposées aux mêmes vecteurs d'attaque, et la pression monte pour que les questionnaires de conformité AI Act intègrent des audits de sécurité de chaîne d'approvisionnement au même titre que les évaluations de risque des modèles.

💬 Quatre attaques en cinquante jours, aucune ne visait les modèles. Pendant qu'on red-teamait les LLMs à coups d'évaluations AISI et de system cards, personne ne regardait les runners CI, les hooks de dépendances, les gates de packaging, et un token OIDC légitime a suffi à publier 84 artefacts malveillants avec une provenance cryptographique valide. La robustesse du modèle, c'est hors-sujet si la chaîne de livraison est trouée.

SécuritéOpinion
1 source
L'IA démultiplie les attaques de désinformation : les défenseurs doivent réagir à la même vitesse
3VentureBeat AI 

L'IA démultiplie les attaques de désinformation : les défenseurs doivent réagir à la même vitesse

L'intelligence artificielle a profondément bouleversé l'économie de la cybersécurité offensive. Un attaquant peut désormais générer en quelques minutes des milliers de leurres de phishing crédibles, de fausses identités et de prétextes sur mesure, le tout pour un coût quasi nul, alors qu'un défenseur n'a pas encore terminé un seul cycle de validation de changement. C'est l'argument central d'une analyse publiée par Splunk, qui insiste sur un déséquilibre fondamental : la tromperie à grande échelle est devenue accessible à tous, tandis que la vérification, elle, n'a pas suivi le même rythme. Pour les équipes de sécurité, l'enjeu ne se résume pas à améliorer les modèles de détection. Le vrai goulot d'étranglement, selon Splunk, est la donnée elle-même : où elle se trouve, si elle est disponible au bon moment, à quelle vitesse elle peut être corrélée, combien de temps elle est conservée, et si les analystes ou les agents d'IA peuvent s'y fier. Un exemple concret illustre le problème : une connexion suspecte depuis le compte d'un prestataire peut sembler anodine isolément. Pour comprendre si elle représente une menace réelle, les équipes doivent croiser l'historique d'identité, l'activité des terminaux, les journaux d'accès cloud, les tickets de support, les changements de configuration et le contexte métier. Si ces informations sont éparpillées dans des outils différents avec des durées de rétention variables, les défenseurs ne mènent plus une enquête ; ils négocient avec leur propre infrastructure de données. Et si les données fournies à une IA sont incomplètes, obsolètes ou fragmentées, l'IA n'apporte pas de certitude : elle accélère l'incertitude. Face à cette réalité, Splunk plaide pour que les organisations repensent fondamentalement le rôle de leurs plateformes de sécurité. Les SIEM et les lacs de données ont longtemps été traités comme des dépôts passifs, de simples archives pour recherches ultérieures, et ce modèle ne suffit plus. Ce dont les entreprises ont besoin aujourd'hui, c'est d'un plan de contrôle défensif : une couche architecturale qui relie ce qui s'est passé, ce que cela signifie et ce que l'organisation est autorisée à faire en conséquence. Concrètement, cela implique quatre capacités : préserver les preuves de manière pérenne, accéder aux données où qu'elles se trouvent, ajouter du contexte métier, et gouverner les actions de façon auditable et défendable. L'IA ne réduit pas l'exigence de disposer de registres fiables, elle en élève le standard. A mesure que les attaquants utilisent l'IA pour industrialiser la déception, les défenseurs doivent l'utiliser pour industrialiser la vérification, et cela commence par une architecture de données digne de confiance.

SécuritéOpinion
1 source
L'injection de prompts exploite les failles de conception des IA d'entreprise : agents, pipelines RAG et routeurs de modèles ciblés
4VentureBeat AI 

L'injection de prompts exploite les failles de conception des IA d'entreprise : agents, pipelines RAG et routeurs de modèles ciblés

L'injection de prompts s'est imposée comme la menace la plus critique pesant sur les systèmes d'intelligence artificielle en entreprise, selon plusieurs rapports convergents publiés entre 2025 et 2026. L'OWASP LLM Top 10 (édition 2025) la classe en première position pour la deuxième édition consécutive, reconnaissant l'incapacité persistante des grands modèles de langage à distinguer fiablement les instructions des données qu'ils traitent. Le rapport CrowdStrike Global Threat Report 2026, s'appuyant sur le suivi de plus de 280 groupes d'adversaires, documente des injections de prompts malveillants dans des outils d'IA générative légitimes au sein de plus de 90 organisations en 2025, utilisées pour voler des identifiants et des cryptomonnaies. Les attaquants pilotés par l'IA ont augmenté leur volume d'attaques de 89 % en un an, résumant la situation en une formule : "Les prompts sont le nouveau malware." Deux incidents concrets illustrent l'ampleur réelle du problème. En août 2024, des chercheurs de PromptArmor ont révélé une faille dans Slack AI permettant d'exfiltrer des données de canaux privés, y compris des clés API, simplement en plaçant une instruction malveillante dans un canal public. En juin 2025, Aim Security a divulgué EchoLeak (CVE-2025-32711, score CVSS 9.3), premier exploit zero-click documenté contre un système IA en production : en envoyant un seul email piégé, sans aucune interaction de l'utilisateur, un attaquant pouvait forcer Microsoft 365 Copilot à transmettre des fichiers internes vers un serveur externe. Les deux vulnérabilités ont depuis été corrigées. L'impact de ces attaques dépasse largement le cas isolé : elles exposent une faille structurelle dans la manière dont les entreprises déploient l'IA à grande échelle. Lorsqu'un modèle traite des instructions, résume des informations et déclenche des workflows automatisés, il devient difficile de distinguer une commande légitime d'une donnée corrompue. Les agents IA modernes peuvent envoyer des emails, modifier des infrastructures cloud, exécuter du code et interagir avec des systèmes internes, ce qui signifie qu'une seule instruction malveillante peut déclencher des actions aux conséquences réelles et durables. Le problème touche directement les équipes de sécurité, les DSI et les développeurs qui déploient ces systèmes sans protocoles de validation robustes. Les techniques d'injection ont considérablement évolué, ciblant désormais des architectures bien plus complexes que le simple chatbot. L'injection inter-modèles exploite le fait que la sortie corrompue d'un modèle sera traitée par d'autres modèles en aval, propageant ainsi la manipulation à travers toute la chaîne. L'empoisonnement de pipelines RAG consiste à publier des contenus malveillants (documentations, articles, READMEs GitHub) en espérant qu'ils soient ingérés par les systèmes de récupération d'information des entreprises. Le détournement d'agents et les attaques par débordement de contexte, utilisant des fenêtres de millions de tokens pour noyer les garde-fous dans un flot de données, complètent un arsenal en constante expansion. Face à cette réalité, la question n'est plus de savoir si une organisation sera ciblée, mais à quel moment ses pipelines IA seront compromis, et si elle aura mis en place les contrôles nécessaires pour le détecter.

UELes entreprises françaises et européennes déployant Microsoft 365 Copilot, des agents IA ou des pipelines RAG sont directement exposées aux vecteurs documentés, notamment EchoLeak (CVE-2025-32711, CVSS 9.3) qui permettait l'exfiltration silencieuse de fichiers internes sans interaction utilisateur.

SécuritéOpinion
1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour

Gratuit · 1 email le matin, l'essentiel de l'IA · désinscription en un clic