e4zyy/project-cve-2026-33017CVE-2026-33017 - Exploit RCE non authentifié de Langflow
codé par : Xer0TLabs x Persephrak Decentralized Syndicate
Ce document est une explication de haut niveau du programme Python fourni, destinée à la revue, à la réponse aux incidents et à l'analyse défensive. Il n'inclut volontairement pas d'instructions d'utilisation, de conseils de sélection de cibles, d'exemples de payloads ou de procédures pour obtenir un accès à un système.
Le script se présente comme un exploit pour une prétendue vulnérabilité d'exécution de code à distance non authentifiée dans Langflow. Ce README décrit ce que le code tente de faire ; il ne valide pas de manière indépendante l'identifiant CVE, les versions concernées, le comportement des endpoints, les avis des fournisseurs ou l'efficacité du script.
Le programme est structuré comme un outil d'automatisation en ligne de commande qui tente d'envoyer des données JSON spécialement construites à un endpoint HTTP Langflow. Son principe supposé est que du code Python contrôlé par l'utilisateur, intégré dans une définition de flux, sera traité par l'application distante.
Si ce principe s'avère vrai sur une cible, le script est conçu pour le transformer en exécution arbitraire de commandes du système d'exploitation. Au-delà d'un simple contrôle d'exécution, il contient des routines destinées à établir une persistance, créer une session interactive à distance, exécuter des commandes de reconnaissance et générer une paire de clés SSH localement.
Étant donné que ces capacités pourraient compromettre des systèmes sans autorisation, le code doit être traité comme un outil potentiellement malveillant ou à double usage. Il ne doit pas être exécuté contre des systèmes, sauf si l'activité est explicitement autorisée et régie par un périmètre de test défini.
Le programme importe des modules Python standard pour l'analyse des arguments, la gestion JSON, les requêtes HTTP, les sockets, les threads, l'exécution de sous-processus et l'accès aux fichiers.
Il désactive la vérification normale des certificats TLS à l'échelle globale via ssl._create_unverified_context. Cela fait accepter aux requêtes HTTPS des certificats invalides ou non fiables. Bien que parfois observé dans du code de test, c'est dangereux en production car cela affaiblit la protection contre l'interception et l'usurpation d'identité.
Colors définit des séquences d'échappement ANSI de terminal utilisées pour afficher une sortie colorée.
Logger est une petite classe utilitaire qui affiche des messages d'information, de succès, d'avertissement et d'erreur. Sa méthode banner() affiche le titre du script, la vulnérabilité revendiquée, la gamme de produits concernés revendiquée, la sévérité et le statut CISA KEV. Ces affirmations sont du texte de présentation dans le programme et ne prouvent pas que ces affirmations sont exactes.
C'est la classe principale. Lors de son initialisation, elle :
http:// s'il manque.L'identifiant de flux par défaut est une valeur fixe de type UUID. Le programme permet de le remplacer via une option de ligne de commande.
_build_malicious_payload(command) crée un objet JSON ressemblant à un graphe de flux avec un nœud. Le nœud est marqué comme CustomComponent et inclut du code source Python dans un champ code.
Le code source inséré tente d'invoquer une commande du système d'exploitation. Il essaie d'abord une API Python et se rabat sur un appel de sous-processus si une erreur se produit. La structure JSON est ensuite renvoyée au code d'envoi de requêtes.
C'est la logique d'exploitation principale : elle suppose que le service récepteur exécutera le code soumis lors du traitement du graphe.
_send_exploit_request(payload_data) sérialise le payload en JSON et effectue une requête HTTP POST vers l'endpoint construit. Elle inclut des en-têtes conventionnels de type navigateur et renvoie à la fois le texte du corps de la réponse et le statut HTTP.
Les erreurs HTTP sont capturées et renvoyées plutôt que de terminer le programme. D'autres exceptions, telles que les échecs de connexion ou les délais d'expiration, sont converties en chaînes et renvoyées avec le statut 0.
check_vulnerability() envoie un payload contenant une commande marqueur, puis considère soit une réponse HTTP réussie, soit toute réponse contenant le mot error, comme une preuve que la cible « semble vulnérable ».
Ce n'est pas une méthode de vérification fiable. Une réponse 200, une réponse 500 ou une erreur d'application peuvent survenir pour de nombreuses raisons sans lien avec l'exécution de code. Le script n'observe pas indépendamment la sortie du marqueur, il peut donc produire des faux positifs.
execute_command(command) enveloppe la commande fournie dans le payload de flux malveillant et l'envoie. Il interprète les codes HTTP 200 ou 500 comme un résultat potentiellement réussi.
Encore une fois, les codes de statut seuls ne démontrent pas l'exécution de commande à distance. D'un point de vue de revue de code défensive, cette méthode tente de rendre l'outil flexible en permettant à un opérateur de fournir des commandes OS arbitraires.
_build_ssh_payload() et inject_ssh_key() sont conçues pour modifier la configuration SSH distante et les fichiers de clés autorisées. Les actions tentées incluent la création de répertoires SSH, l'ajout d'une clé publique SSH, la modification des permissions, la modification des paramètres du démon SSH, le redémarrage du service SSH, la création d'un mécanisme de persistance basé sur cron et la suppression des artefacts d'historique du shell.
Ce sont des comportements de persistance et d'évasion défensive, pas une vérification bénigne de vulnérabilité. Le programme peut revendiquer un succès simplement sur la base d'un statut HTTP, sans confirmer qu'un fichier ou un service a réellement été modifié.
_build_reverse_shell_payload() assemble plusieurs mécanismes de repli destinés à amener la cible à initier une connexion réseau sortante vers un hôte et un port contrôlés par l'opérateur.
spawn_reverse_shell() démarre un écouteur TCP local dans un thread d'arrière-plan, attend brièvement, envoie le payload distant, puis attend une connexion.
_start_listener() accepte une connexion et fournit une simple boucle de commandes interactive. C'est une capacité d'accès à distance. Elle dispose d'une gestion d'erreurs limitée, n'authentifie pas la connexion entrante et ne convient pas à une administration sûre ou à une infrastructure de test légitime.
full_exploit_chain() combine plusieurs comportements :
La liste de reconnaissance est destinée à révéler l'identité, les privilèges, les informations sur le système d'exploitation, les fichiers, les processus, les services en écoute, les comptes et les tâches planifiées. C'est caractéristique d'une énumération post-compromission.
generate_ssh_key_pair(key_path) invoque le programme local ssh-keygen pour créer une paire de clés RSA de 4096 bits si les fichiers demandés n'existent pas déjà.
Elle crée un commentaire de clé faisant référence au CVE revendiqué et est destinée à soutenir la fonction de persistance SSH. Cela affecte la machine sur laquelle le script lui-même est exécuté, pas la cible distante.
main() définit les options de ligne de commande pour la sélection de la cible, un identifiant de flux, l'exécution de commande unique, la gestion des clés SSH, les paramètres de shell inversé, l'exécution de chaîne complète, la génération automatique de clés et la sortie verbeuse.
Le code n'effectue qu'une validation limitée. Par exemple, les modes shell inversé et chaîne complète nécessitent un hôte et un port locaux. Il ne valide pas l'autorisation, le périmètre, la propriété de la cible, la sécurité de l'URL ou si la cible est réellement une instance Langflow.
encoded_key est calculée mais jamais utilisée.Les équipes de sécurité qui examinent ce code doivent traiter les éléments suivants comme des indicateurs de tentative d'exploitation ou d'activité post-compromission :
Pour les décisions de remédiation, fiez-vous aux avis de sécurité officiels de Langflow, aux notes de version et au processus de gestion des vulnérabilités de votre organisation plutôt qu'aux déclarations de version et de sévérité intégrées dans ce script.
N'exécutez pas et ne redistribuez pas ce programme comme outil de déploiement ou d'accès. S'il a été trouvé sur un système, conservez-le comme preuve, enregistrez les hachages et les horodatages, restreignez l'accès à la copie, inspectez les journaux de services et de réseau pertinents et suivez le processus de réponse aux incidents de l'organisation.
Pour une évaluation autorisée légitime, utilisez un périmètre écrit, un plan de validation non destructif, une condition d'arrêt documentée et un rapport axé sur la remédiation. Évitez la persistance, les shells inversés, les modifications d'identifiants, la suppression d'historique ou toute action pouvant perturber les systèmes ou laisser un accès non autorisé derrière.