CVE-2026-33017 dans Langflow: exécution à distance du code sans authentification et fonctionnement en seulement 20 heures

Un grave échec de sécurité à Langflow a récemment mis une réalité inconfortable sur la table à nouveau: des outils ouverts pour construire et orchestrer des modèles IA sont maintenant des cibles attrayantes pour les attaquants et tout échec peut devenir une piste rapide pour les serveurs compromis. Il s'agit de la vulnérabilité enregistrée comme CVE-2026-33017 (CVSS 9.3), qui permet l'exécution à distance du code sans authentification dans les versions Langflow avant ou après 1.8.1.

Langflow, une plateforme open source conçue pour créer et exécuter des « flux » d'IA, expose un paramètre public qui ne devrait servir que le contenu stocké par le serveur. Cependant, l'implémentation a permis un paramètre optionnel appelé « données » pour remplacer les flux enregistrés par des données fournies par la personne qui fait la demande. Ces données pourraient contenir des définitions de nœuds avec des fragments de Python qui ont finalement été exécutés par exec () sans aucune sorte d'isolement. Le résultat est simple et dangereux : une seule requête HTTP peut déclencher un code arbitraire avec les permissions du processus Langflow.

Celui qui a découvert la faiblesse, le chercheur Aviral Srivastava, a publié son analyse technique et la façon de la reproduire, et a proposé une solution claire : éliminer la possibilité d'un paramètre public acceptant ce paramètre d'entrée et forcer seulement les flux stockés sur le serveur à être exécutés. Votre explication complète peut être lue dans votre post technique à Moyenne et la réponse et le suivi du projet sont disponibles dans le dépôt de C'est pas vrai..

Ce qui rend ce cas encore plus inquiétant, c'est la vitesse à laquelle la vulnérabilité a été exploitée dans des environnements réels. L'équipe de sécurité de Sysdig a signalé qu'elle avait détecté des tentatives d'exploitation sur Internet seulement 20 heures après la publication de l'avis. Selon leur enquête, les agresseurs n'ont pas attendu l'apparition du code public de preuve de concept : ils ont construit des exploits à partir de la description de l'échec, scanné les systèmes exposés et commencé à extraire des lettres de créances et d'autres secrets. Le rapport technique Sysdig fournit plus de détails et d'exemples de la campagne, et est disponible sur votre blog: Sysdig.

Avec le contrôle d'un processus vulnérable, un attaquant peut lire des variables d'environnement contenant des clés, accéder à des fichiers sensibles, installer des portes arrière ou même monter un shell distant. Sysdig a documenté que, après la phase de numérisation automatisée, les opérateurs ont continué à utiliser des scripts Python personnalisés pour extraire des fichiers tels que "/ etc / passé" puis télécharger une deuxième étape hébergée sur un serveur externe, indiquant un plan d'exploitation échelonné et une trousse d'outils préparée pour déployer des charges utiles spécifiques.

Cet épisode s'inscrit dans une tendance plus large : le temps entre la publication d'une vulnérabilité et son exploitation publique a été considérablement comprimé ces dernières années. Rapports de sécurité, tels que 2026 Rapport sur le paysage des menaces mondiales de Rapid7, montrent que les délais ont été réduits et que de nombreux agresseurs consultent maintenant les mêmes sources d'avertissement que les défenseurs. En outre, la Cyber Security Agency des États-Unis tient à jour le catalogue des vulnérabilités exploitées connues, un rappel que ces échecs restent rarement inactifs pendant longtemps.

Face à ce scénario, des recommandations pratiques pour les gestionnaires et les équipes utilisant Langflow sont urgentes et concrètes. Mise à jour d'une version corrigée dès qu'elle est disponible est la priorité; le patch a été intégré dans le travail de développement (par exemple, il ya des changements dans la branche de développement 1.9.0.dev8) et le projet a publié des informations sur l'atténuation. En outre, il convient de vérifier et de faire pivoter les lettres de créance et les secrets présents dans les cas accessibles au public, d'examiner les journaux à la recherche d'appels inattendus vers le paramètre touché et de surveiller les connexions sortantes suspectes qui peuvent indiquer l'exfiltration ou les rappels de l'agresseur.

Il n'est pas moins important de réduire l'exposition de ces services : filtrer le trafic par les règles du pare-feu, placer Langflow derrière un inverse mandataire qui nécessite une authentification pour l'accès administratif et limiter l'accès aux environnements de production. En parallèle, l'évaluation de la possibilité d'offrir des flux publics par une couche intermédiaire qui valide les données stockées sur le serveur et n'exécute que des données empêcherait les entrées externes d'atteindre directement les fonctions d'exécution de code.

Cet incident laisse également une leçon technique pour les développeurs : exécuter un code arbitraire à partir d'entrées peu fiables est une source récurrente d'engagements critiques. L'utilisation de fonctions telles que exec () sans bac à sable ou validation rigoureuse, et si nécessaire, des contrôles stricts et des mécanismes de confinement devraient être accompagnés.

Bref, l'exploitation de CVE-2026-33017 rappelle que l'écosystème des outils pour l'IA doit améliorer ses pratiques de sécurité à la même vitesse avec laquelle de nouvelles fonctionnalités sont développées. Les communautés open-source, les entreprises qui déploient ces solutions et les équipes de sécurité doivent être coordonnées pour fermer les vecteurs d'attaque avant que les attaquants ne les transforment en engagement de masse.

L'analyse Sysdig se trouve dans Sysdig, les conseils de sécurité dans le dépôt de C'est pas vrai., le compte technique du découvreur en Moyenne et le contexte des tendances Rapide7. Si vous gérez les instances Langflow, agissez rapidement : mettre à jour et vérifier aujourd'hui peut éviter un compromis demain.