e4zyy/project-cve-2026-33017CVE-2026-33017 – Langflow-Exploit für nicht authentifizierte Remote-Codeausführung (RCE)
codiert von: Xer0TLabs x Persephrak Decentralized Syndicate
Dieses Dokument ist eine allgemeine Erklärung des bereitgestellten Python-Programms zur Überprüfung, Incident-Response und defensiven Analyse. Es enthält bewusst keine Betriebsanleitungen, Zielauswahl-Hinweise, Payload-Beispiele oder Verfahren zum Erlangen von Systemzugriff.
Das Skript bezeichnet sich selbst als Exploit für ein behauptetes Langflow-Problem mit nicht authentifizierter Remote-Codeausführung. Diese README beschreibt, was der Code zu tun versucht; sie validiert weder die CVE-Kennung, betroffene Versionen, Endpunkt-Verhalten, Herstellerhinweise noch die Wirksamkeit des Skripts unabhängig.
Das Programm ist als Kommandozeilen-Automatisierungswerkzeug strukturiert, das versucht, speziell konstruierte JSON-Daten an einen Langflow-HTTP-Endpunkt zu senden. Seine beabsichtigte Prämisse ist, dass benutzergesteuertes Python, das in einer Flow-Definition eingebettet ist, von der entfernten Anwendung verarbeitet wird.
Wenn diese Prämisse auf einem Ziel zutrifft, ist das Skript darauf ausgelegt, daraus eine beliebige Betriebssystem-Befehlsausführung zu machen. Über eine grundlegende Ausführungsprüfung hinaus enthält es Routinen, die darauf abzielen, Persistenz herzustellen, eine interaktive Remote-Sitzung zu erstellen, Aufklärungsbefehle auszuführen und lokal ein SSH-Schlüsselpaar zu erzeugen.
Da diese Fähigkeiten Systeme ohne Autorisierung kompromittieren könnten, sollte der Code als potenziell bösartiges oder Dual-Use-Werkzeug behandelt werden. Er sollte nicht gegen Systeme ausgeführt werden, es sei denn, die Aktivität ist ausdrücklich autorisiert und durch einen definierten Testumfang geregelt.
Das Programm importiert Standard-Python-Module für Argument-Parsing, JSON-Handling, HTTP-Anfragen, Sockets, Threads, Subprozess-Ausführung und Dateizugriff.
Es deaktiviert die normale TLS-Zertifikatsprüfung global über ssl._create_unverified_context. Dadurch akzeptieren HTTPS-Anfragen ungültige oder nicht vertrauenswürdige Zertifikate. Obwohl dies manchmal in Testcode vorkommt, ist es in der Produktion unsicher, da es den Schutz vor Abfangen und Identitätsvortäuschung schwächt.
Colors definiert ANSI-Terminal-Escape-Sequenzen, die zum Drucken von farbigem Output verwendet werden.
Logger ist eine kleine Hilfsklasse, die Informations-, Erfolgs-, Warn- und Fehlermeldungen ausgibt. Ihre banner()-Methode zeigt den Titel des Skripts, die behauptete Schwachstelle, den behaupteten betroffenen Produktbereich, den Schweregrad und den CISA-KEV-Status an. Diese Behauptungen sind Präsentationstext im Programm und kein Beweis dafür, dass die Behauptungen korrekt sind.
Dies ist die Hauptklasse. Bei der Initialisierung:
http://-Präfix hinzu, falls eines fehlt.Die Standard-Flow-ID ist ein fester UUID-ähnlicher Wert. Das Programm erlaubt es, sie über eine Kommandozeilenoption zu überschreiben.
_build_malicious_payload(command) erstellt ein JSON-Objekt, das einem Flow-Graphen mit einem Knoten ähnelt. Der Knoten ist als CustomComponent markiert und enthält Python-Quellcode in einem code-Feld.
Der eingefügte Quellcode versucht, einen Betriebssystembefehl aufzurufen. Er versucht zuerst eine Python-API und fällt auf einen Subprozess-Aufruf zurück, wenn ein Fehler auftritt. Die JSON-Struktur wird dann an den Anfrage-sendenden Code zurückgegeben.
Dies ist die Kern-Exploit-Logik: Sie nimmt an, dass der empfangende Dienst den übermittelten Code während der Verarbeitung des Graphen ausführt.
_send_exploit_request(payload_data) serialisiert die Payload als JSON und sendet eine HTTP-POST-Anfrage an den konstruierten Endpunkt. Sie enthält konventionelle browserähnliche Header und gibt sowohl den Antworttext als auch den HTTP-Status zurück.
HTTP-Fehler werden abgefangen und zurückgegeben, anstatt das Programm zu beenden. Andere Ausnahmen, wie Verbindungsfehler oder Timeouts, werden in Zeichenfolgen umgewandelt und mit Status 0 zurückgegeben.
check_vulnerability() sendet eine Payload mit einem Marker-Befehl und behandelt dann entweder eine erfolgreiche HTTP-Antwort oder jede Antwort, die das Wort error enthält, als Beweis dafür, dass das Ziel „anfällig erscheint“.
Dies ist keine zuverlässige Verifizierungsmethode. Eine 200-Antwort, eine 500-Antwort oder ein Anwendungsfehler kann aus vielen Gründen auftreten, die nichts mit Codeausführung zu tun haben. Das Skript beobachtet die Ausgabe des Markers nicht unabhängig, daher kann es Fehlalarme erzeugen.
execute_command(command) verpackt den bereitgestellten Befehl in die bösartige Flow-Payload und sendet sie. Es interpretiert HTTP 200 oder 500 als mögliches erfolgreiches Ergebnis.
Auch hier zeigen Statuscodes allein keine Remote-Befehlsausführung. Aus defensiver Code-Review-Perspektive versucht diese Methode, das Werkzeug flexibel zu machen, indem sie einem Bediener erlaubt, beliebige OS-Befehle bereitzustellen.
_build_ssh_payload() und inject_ssh_key() sind darauf ausgelegt, die entfernte SSH-Konfiguration und Authorized-Keys-Dateien zu modifizieren. Die versuchten Aktionen umfassen das Erstellen von SSH-Verzeichnissen, das Hinzufügen eines SSH-öffentlichen Schlüssels, das Ändern von Berechtigungen, das Modifizieren von SSH-Daemon-Einstellungen, das Neustarten des SSH-Dienstes, das Erstellen eines Cron-basierten Persistenzmechanismus und das Entfernen von Shell-Verlaufsartefakten.
Dies sind Persistenz- und Verteidigungsumgehungs-Verhaltensweisen, keine harmlose Schwachstellenprüfung. Das Programm kann Erfolg lediglich basierend auf einem HTTP-Status behaupten, ohne zu bestätigen, dass eine Datei oder ein Dienst tatsächlich geändert wurde.
_build_reverse_shell_payload() setzt mehrere Fallback-Mechanismen zusammen, die dazu dienen, das Ziel zu veranlassen, eine ausgehende Netzwerkverbindung zu einem bedienerkontrollierten Host und Port aufzubauen.
spawn_reverse_shell() startet einen lokalen TCP-Listener in einem Hintergrund-Thread, wartet kurz, sendet die Remote-Payload und wartet dann auf eine Verbindung.
_start_listener() akzeptiert eine Verbindung und stellt eine einfache interaktive Befehlsschleife bereit. Dies ist eine Remote-Zugriffsfähigkeit. Sie hat eine begrenzte Fehlerbehandlung, authentifiziert die eingehende Verbindung nicht und ist nicht für sichere Administration oder legitime Testinfrastruktur geeignet.
full_exploit_chain() kombiniert mehrere Verhaltensweisen:
Die Aufklärungsliste soll Identität, Berechtigungen, Betriebssysteminformationen, Dateien, Prozesse, lauschende Dienste, Konten und geplante Aufgaben offenlegen. Dies ist charakteristisch für Post-Kompromittierungs-Enumeration.
generate_ssh_key_pair(key_path) ruft das lokale ssh-keygen-Programm auf, um ein 4096-Bit-RSA-Schlüsselpaar zu erstellen, falls die angeforderten Dateien nicht bereits existieren.
Es erstellt einen Schlüsselkommentar, der sich auf die behauptete CVE bezieht, und soll die SSH-Persistenzfunktion unterstützen. Dies betrifft die Maschine, auf der das Skript selbst ausgeführt wird, nicht das entfernte Ziel.
main() definiert Kommandozeilenoptionen für Zielauswahl, eine Flow-ID, Einzelbefehlsausführung, SSH-Schlüssel-Handling, Reverse-Shell-Einstellungen, Full-Chain-Ausführung, automatische Schlüsselerzeugung und ausführliche Ausgabe.
Der Code führt nur eine begrenzte Validierung durch. Beispielsweise erfordern Reverse-Shell- und Full-Chain-Modi einen lokalen Host und Port. Er validiert keine Autorisierung, keinen Umfang, kein Ziel-Eigentum, keine URL-Sicherheit und nicht, ob das Ziel tatsächlich eine Langflow-Instanz ist.
encoded_key wird berechnet, aber nie verwendet.Sicherheitsteams, die diesen Code überprüfen, sollten Folgendes als Indikatoren für versuchte Ausnutzung oder Post-Kompromittierungs-Aktivität behandeln:
Für Sanierungsentscheidungen verlassen Sie sich auf die offiziellen Langflow-Sicherheitshinweise, Versionshinweise und den Schwachstellenmanagement-Prozess Ihrer Organisation, nicht auf die in diesem Skript eingebetteten Versions- und Schweregrad-Aussagen.
Führen Sie dieses Programm nicht als Bereitstellungs- oder Zugriffswerkzeug aus oder verteilen Sie es nicht weiter. Wenn es auf einem System gefunden wurde, bewahren Sie es als Beweismittel auf, dokumentieren Sie Hashes und Zeitstempel, beschränken Sie den Zugriff auf die Kopie, prüfen Sie relevante Dienst- und Netzwerkprotokolle und befolgen Sie den Incident-Response-Prozess der Organisation.
Für eine legitime autorisierte Bewertung verwenden Sie einen schriftlichen Umfang, einen nicht-destruktiven Validierungsplan, eine dokumentierte Abbruchbedingung und einen auf Sanierung ausgerichteten Bericht. Vermeiden Sie Persistenz, Reverse Shells, Anmeldedatenänderungen, Verlaufslöschung oder jede Aktion, die Systeme stören oder unbefugten Zugriff hinterlassen kann.