CVE-2025-34291: Langflow AI Intelligence Body und Workflow-Plattform Kontoübernahme und Remotecode-Ausführung Sicherheitslücke

1. der Hintergrund

Eine Wertmarke kann Ihnen oder demjenigen, der sie besitzt, Türen öffnen.

aktuelleSalesloft-DriftDer Vorfall macht deutlich, welchen Schaden solche Angriffe anrichten können. Der Angreifer, UNC6395, nutzte gestohlene OAuth-Tokens, um in großem Umfang Daten von rund 700 Salesforce-Organisationen zu stehlen, darunter große Tech-Unternehmen wie Cloudflare, Zscaler und Palo Alto Networks.

Künstliche Intelligenz (KI)代理和工作流平台已成为外部服务和数据系统的集成中心。每次集成都会增加更多凭证，将敏感访问权限集中在一处。这种集中化使得攻击者成为高价值目标：一次安全漏洞就可能让攻击者获得所有连接系统的“主密钥”。

Bei gemeinsam genutzten Plattformen könnte eine einzige Sicherheitslücke mehrere Organisationen betreffen; bei selbst gehosteten Plattformen könnte eine einzige Sicherheitslücke mehrere Dienste innerhalb einer einzigen Organisation gefährden. Angesichts dieser Risiken haben wir eine Reihe bekannter Open-Source-KI-Agenten und Workflow-Plattformen einer Sicherheitsbewertung unterzogen, um potenzielle Schwachstellen zu ermitteln, die zu einem vollständigen Zusammenbruch des zugrunde liegenden Systems führen könnten.

Als primären Forschungsgegenstand wählten wir Langflow - ein Open-Source-Visualisierungs-Framework für die Erstellung von KI-Workflows, RAG-Anwendungen und Multi-Intelligenz-Systemen mit mehr als 140.000 Sternen auf GitHub.Langflow basiert auf Python und FastAPI Langflow basiert auf Python und FastAPI und bietet eine intuitive Drag-and-Drop-Schnittstelle, mit der Entwickler komplexe KI-Anwendungen erstellen können, ohne viel Code schreiben zu müssen.

‍

‍

Bemerkenswert ist, dass Langflow im April 2024 von DataStax übernommen wurde, das derzeit von IBM übernommen wird (angekündigt im Februar 2025), wodurch Langflow Teil des expandierenden KI-Portfolios Watsonx von IBM wird.

2、Langfluss-Tiefenanalyse und Anwendung

2.1, CVE-2025-3248: zwei Jahre der Geschichte

Langflow ist ein junges und sich schnell entwickelndes Projekt - genau die Art von Projekt, die einen tieferen Einblick in seine Sicherheit verdient. Ein guter Einstiegspunkt ist die Geschichte seiner Sicherheitslücken. Erst vor ein paar Monaten tauchte die Sicherheitslücke CVE-2025-3248 auf: eine schwerwiegende und nicht authentifizierte Sicherheitslücke für die Remotecodeausführung, die Versionen vor 1.3.0 betrifft.

Was wirklich auffällt, ist nicht nur die Schwere des Problems, sondern auch die Geschichte dahinter: fast zwei Jahre von der ersten Entdeckung bis zur endgültigen Behebung, ein ungewöhnlich langer Zeitraum, der die architektonischen Kompromisse und die Entwicklung der Sicherheitslage von Langflow offenbart.

Zeitplan für die Entdeckung und Beseitigung von Mängeln:

• 27. Juli 2023GitHub-Benutzer @Lyutoon hat ein Issue eingereicht #696Es wird darauf hingewiesen, dass nicht authentifizierte Codevalidierungsendpunkte über Standardparameter in Funktionsdefinitionen für Remote Code Execution (RCE) ausgenutzt werden können.
• 10. November 2024: Github-Benutzer @nimasteryang hat einen Pull-Antrag eingereicht #4488Es wurde versucht, die Schwachstelle zu beheben, aber die Behebung wurde aufgegeben, da sie die bestehende Funktionalität beeinträchtigt hätte.
• 22. Februar 2025 Horizont3.aiSicherheitsforscher meldeten eine Schwachstelle in Langflow über GitHub Security Issues und entdeckten einen zweiten, anderen RCE-Vektor, der einen Funktionsdekorator ausnutzt, um während der Codevalidierung einen RCE auszulösen.
• Schreiben vom 3. März 2025 des Ständigen Vertreters von: Langflow-Team über anfällige Endpunkte#6911Implementieren Sie Authentifizierungsanforderungen, um die Sicherheitslücke CVE-2025-3248 formell zu beheben.

Die Entwicklung der letzten zwei Jahre zeigt einen bekannten Zielkonflikt: Vor allem im Bereich der künstlichen Intelligenz (KI) bemühen sich die Teams darum, die Akzeptanz zu erhöhen, während die Sicherheit auf der Strecke bleibt.

2.2 Schwachstellen: ein kurzer Überblick

Schauen wir uns kurz an, wie diese Schwachstelle funktioniert.

Das Kernproblem ergibt sich aus Langflow's/api/v1/validate/codeEine Schnittstelle für die Authentifizierung von Python-Codefragmenten für benutzerdefinierte Komponenten. Vor Version 1.3.0 konnte auf diese Schnittstelle jedoch auch ohne Authentifizierung zugegriffen werden:

src/backend/base/langflow/api/v1/validate.py

‍

solltevalidate_code()Die Funktion analysiert den übergebenen Code, prüft, ob er Funktionsdefinitionen enthält, und führt dann diese Funktionen aus, um sie zu überprüfen:

src/backend/base/langflow/utils/validate.py

Dieser Code geht davon aus, dass Funktionsdefinitionen sicher ausgeführt werden können. Das ist aber nicht der Fall. Wenn die Funktion `exec()` eine Funktionsdefinition ausführt, führt sie sofort die Standardargumente und den Ausdruck im Dekorator aus.

‍

Ohne den Sandboxing-Mechanismus könnte jeder nicht authentifizierte Benutzer das System vollständig kompromittieren, indem er eine POST-Anfrage an den Server sendet/api/v1/validate/code.

Diese Schwachstelle wurde aktiv von Bedrohungsakteuren ausgenutzt, die das Flodric-Botnet über kompromittierte Langflow-Instanzen einsetzen.Trend Micro StudieDies wurde aufgezeichnet.

3. von der Offenheit zur Geschlossenheit

Als Reaktion auf CVE-2025-3248 haben wir dem Endpunkt /api/v1/validate/code Authentifizierungsfunktionen hinzugefügt. Wenn eine Anfrage diesen Endpunkt erreicht, löst der Mechanismus der Abhängigkeitsinjektion von FastAPI automatisch den Authentifizierungsprozess aus.

3.1 Anforderungen an die Authentifizierung von Endpunktangaben

‍

3.2 Überprüfen Sie, ob das Benutzerkonto aktiv ist.

‍

3.3 Durchführung physischer Authentifizierungsprüfungen

Die Funktion get_current_user() überprüft beide Authentifizierungsquellen in der Reihenfolge ihrer Priorität:

in erster LinieJWT-Token aus Authorization: Bearer header

zweite ArtAPI-Schlüssel aus x-api-key-Header oder Abfrageparameter

Der Endpunkt für die Codevalidierung ist nach der Veröffentlichung des Patches nicht mehr standardmäßig geöffnet. Der Zugriff auf diesen Endpunkt erfordert jetzt ein gültiges JWT-Token oder einen gültigen API-Schlüssel.‍

4. von geschützt bis durchgesickert:CVE-2025-34291

In der Theorie sieht die Authentifizierung perfekt aus. Die praktische Frage lautet daher: Können wir auf gültige Berechtigungsnachweise zugreifen oder sie nutzen? Die folgenden drei Bereiche sind von Interesse:

1) API-Schlüssel

Die Aussichten sind besorgniserregend. Der API-Schlüssel wird standardmäßig nicht automatisch konfiguriert und muss vom Benutzer in den Einstellungen explizit erstellt werden. Begrenzte Angriffsfläche.

2) CSRF und CORS?

Dies ist ein interessanter Weg. Ohne angemessenen CSRF-Schutz kann ein Angreiferseitenübergreifendes SchreibenStellen Sie eine Anfrage als Benutzer. Wenn die CORS-Richtlinie falsch konfiguriert ist, kann ein Angreifer weitere Aktionen durchführenherkunftsübergreifendes Lesenum die sensible Antwort zu erhalten, die von der authentifizierten Anfrage zurückgegeben wird.

3) Stehlen von JWT-Tokens mit XSS

Das Backend generiert und signiert das JWT (HS256) während der Anmeldung und setzt es dann als Teil der HTTP-Antwort an diezugangstoken_lfCookieSameSite=Lax. Das gleiche Token wird in den Text der Antwort aufgenommen.

Das Frontend liest dann dieses Cookie und verwendet die StandardAutorisierung: ÜberbringerHeader enthält dieses Token in allen API-Anfragen.

Mit anderen Worten, der Wert des JWT-Tokens ist derselbe wie der Wert deszugangstoken_lfDer im Cookie gespeicherte Wert ist derselbe. Da Cookies nicht verschlüsselt sindHttpOnlyAus diesem Grund kann clientseitiges JavaScript es lesen - dies erfordert jedoch eine separate XSS-Schwachstelle in Langflow.

Glücklicherweise funktionierte Methode 2: Wir fanden zwei Konfigurationsfehler, die zusammen die Authentifizierung vollständig umgingen.

4.1 CORS-Fehlkonfiguration

Standardmäßig verwendet Langflow die CORSMiddleware von FastAPI mit lockeren Einstellungen, um Anfragen aus beliebigen Quellen zuzulassen. Darüber hinaus wird dieallow_credentialsDiese Einstellung ist auch auf True gesetzt, um einem Angreifer die Möglichkeit zu geben, domänenübergreifende Anfragen mit Anmeldeinformationen zu initiieren.

langflow/main.py#L292-L300

Es gibt jedoch zwei Probleme, die eine weitere Nutzung verhindern:

• Ausgabe 1Authentifizierungs-Cookiezugangstoken_lfkonfiguriertSameSite=Laxwas sie von den meisten seitenübergreifenden Kontexten (XHR/fetch/POST) ausschließen würde, mit Ausnahme der vom Benutzer initiierten GET-Navigation auf oberster Ebene.
• Ausgabe 2In Langflow 1.5 und höher erfordern die meisten API-Endpunkte eine zusätzliche Authentifizierung - entweder durch die Bereitstellung eines Langflow-API-Schlüssels oder durch die Aufnahme eines JWT-Tokens in den Authorisation-Header, der nicht automatisch in domänenübergreifende Anfragen aufgenommen wird.

Daher sollten wir nicht in der Lage sein, authentifizierte domänenübergreifende Anfragen zu senden. Diese CORS-Einrichtung scheint harmlos genug - bis ein übersehenes Detail die Angriffskette neu entfacht.

4.2. refresh_token_lf Cookie-Konfigurationsfehler

sollterefresh_token_lfCookies sind konfiguriertSameSite=None; Sicherwas sie in einem seitenübergreifenden Kontext über HTTPS zugänglich macht. Darüber hinaus ist sie bis zu einer Woche gültig, was Angreifern ein längeres Zeitfenster für Angriffe bietet.

sollte/api/v1/refreshDer Endpunkt verlässt sich ausschließlich auf dieses Cookie als Authentifizierungsmechanismus und implementiert keinen zusätzlichen CSRF-Schutz.

Infolgedessen kann eine domänenübergreifende Anfrage von einer vom Angreifer kontrollierten Domäne/api/v1/refreshEin neues Token-Paar kann erfolgreich erworben werden: ein TokenZugriffstokenund ein neues Tokenrefresh_tokenDies ermöglicht ein vollständiges Session-Hijacking.

‍

Ein Angreifer, der im Besitz eines gültigen Zugriffstokens ist, könnte einfach eine weitere domänenübergreifende Anfrage stellen, um die Sicherheitslücke CVE-2025-3248 auszunutzen und Remotecodeausführung zu ermöglichen.

‍

5. schritte der Vervielfältigung

5.1 Umgebungseinstellungen

1) Konfigurieren Sie Langflow lokal mit Docker Compose und aktivieren Sie HTTPS.::

‍
2. ein Besuch bei Langflow::https://:443Öffnen Sie sie in Ihrem Browser und ersetzen Sie<server-addr>ist die IP/der Hostname des Servers, auf dem Langflow eingesetzt wird.

3. einloggen: Verwenden Sie den Standardadmin:adminAnmeldeinformationen zum Starten einer neuen Benutzersitzung.

5.2 Konzeptnachweis

1. die PoC-Seite öffnen: Navigationhttps://www.pocs.app/langflow-cors-vul-poc.htmlbis

2. die Konfigurationsziele: Ändern Sie die Basis-URL des Ziels, und klicken Sie dann aufExploit starten.

3. das Erleben von WundernInnerhalb weniger Sekunden wird Folgendes passieren:

• POST /api/v1/refreshDer Browser sendet eine domänenübergreifende Anfrage, die das Opfer-Cookie enthält.
• PoC extrahiert undzugangstoken_auffrischen_token
• Sie übergibt dann die/api/v1/validate/codeEndpunkt löst Remote Code Execution (RCE) aus.

4. ergebnisseUmgebungsvariablen oder andere sensible Daten werden auf dem PoC-Terminal-Panel angezeigt.

6. die Auswirkungen von Schwachstellen

Langflow verwendet globale Variablen, um Anmeldedaten und andere gemeinsame Werte prozessübergreifend zu speichern und wiederzuverwenden. Diese Variablen werden dauerhaft in der internen Datenbank gespeichert und ihre Werte werden mit Schlüsseln verschlüsselt.

Sobald das System kompromittiert ist, ist es für einen Angreifer ein Leichtes, diese Werte zu entschlüsseln.

Vollständiges Session Hijacking und Remote Code Execution - Die vollständige Kontrolle über das System kann mit einem einzigen böswilligen Webbesuch erreicht werden. Da die Anfragen vom Browser des Opfers über CORS initiiert werden, können auch nicht-öffentliche, lokal bereitgestellte Instanzen ausgenutzt werden.

Schwachstellen bei der Remote Code Execution (RCE) sind besonders gefährlich im Zusammenhang mit der Rolle von Langflow als KI-Agent und Workflow-Plattform. Angreifer können auf Projektabläufe und privilegierte Anmeldeinformationen zugreifen, die im Arbeitsbereich gespeichert sind, einschließlich API-Schlüsseln, Datenbankpasswörtern und Service-Tokens, die für die Verbindung mit SaaS-, Cloud- und anderen Umgebungen verwendet werden. Dies erweitert die Reichweite des Angriffs über die Langflow-Instanz selbst hinaus und macht Agent Build-Plattformen wie Langflow zu einem Single Point of Failure.

6.1 Sicherheitsempfehlungen

Die Verzögerung von Langflow bei der Veröffentlichung eines vollständigen Fixes scheint auf Bedenken zurückzuführen zu sein, dass die Verschärfung der Cookie/CORS-Einstellungen die Front-End/Back-End-Trennungsimplementierungen unterbrechen könnte.

Aus der Sicherheitsperspektive stellt sich die Frage: Wie sollte der Aktualisierungsendpunkt geschützt werden?

1. wenn die Authentifizierung auf Cookies basiert, muss ein angemessener CSRF-Schutz vorhanden sein. Bei einem standortübergreifenden Einsatz (z. B. https://app.example.com → https://api.example.com, der zwar domänenübergreifend ist, aber immer noch zum selben Standort gehört) kann das Aktualisierungs-Cookie sicher mit SameSite=Lax oder Strict (vorzugsweise mit den beiden Optionen Secure und HttpOnly) verwendet werden. Wenn sich Frontend und Backend nicht auf der gleichen Website befinden Wenn sich das Front-End und das Back-End nicht auf derselben Website befinden und einige Funktionen SameSite=None erfordern, muss ein expliziter CSRF-Token-Mechanismus hinzugefügt werden.

(2) Auffrischungstoken sollten vorzugsweise über HTTP-Header und nicht über Cookies gesendet werden. Die Verwendung von "Authorisation: Bearer " beseitigt das CSRF-Bedrohungsmodell vollständig, vermeidet vom Browser verwaltete Anhänge von Anmeldeinformationen und vereinfacht die CORS-Härtung.

Nicht zuletzt ist die Schwachstelle nicht auf einen einzelnen kritischen Fehler zurückzuführen, sondern war das Ergebnis einer Kombination scheinbar harmloser Konfigurationsentscheidungen, die zusammen eine ernsthafte Angriffsmöglichkeit darstellten. Dieser Vorfall zeigt eine wichtige Lektion: In komplexen Systemen können selbst scheinbar harmlose Designentscheidungen auf unerwartete Weise zusammenwirken. Er unterstreicht die Bedeutung umfassender Sicherheitsüberprüfungen und Standardsicherheitskonfigurationen - insbesondere, da KI-Plattformen zunehmend in Unternehmensabläufe eingebettet werden und immer sensiblere Daten verarbeiten.

6.2 Programm für Abhilfemaßnahmen

Nachdem das Langflow-Team das Problem offengelegt hatte, bestätigte es das Problem und leitete eine Reihe von Korrekturen ein. Laut den Langflow-Entwicklungsprotokollen:

• Version 1.6.0Es wurden neue Umgebungsvariablen eingeführt, die es den Benutzern ermöglichen, die CORS-Konfiguration von Langflow vollständig anzupassen.
• In der kommenden Version 1.7Nachfolgend einige Beispiele für die Programme und Aktivitäten von CORS undrefresh_token_lfDie Cookies werden alle auf sicherere Standardeinstellungen gesetzt:
  • CORS erlaubt nur authentifizierte Anfragen von explizit angegebenen Quellen.
  • refresh_token_lfDas Cookie wird standardmäßig gesetzt aufSameSite=LaxVerringern Sie die standortübergreifende Exposition.

Zum Zeitpunkt der Erstellung dieses Dokuments ist die neueste offizielle Version 1.6.9, und 1-click Remote Code Execution (1-click RCE) ist mit den Standardeinstellungen immer noch vollständig verfügbar.

Organisationen können folgenOffizieller CORS-LeitfadenErweitern Sie die Bereitstellung manuell. Wenn sich das Front-End und das Back-End am selben Standort befinden, können Sie alternativ die PR #10139die Wiederherstellungsverfahren in derREFRESH_SAME_SITEAktualisierungen werden auf der Ebene des Quellcodes vorgenommen.StrictLax

Darüber hinaus arbeitet das Langflow-Team an einem Code-Validierungs-Endpunkt für die#10696Entwicklungs-Sandbox. Damit ist das Risiko der Remotecode-Ausführung hoffentlich ein für alle Mal gebannt.

6.3 Zeitplan für die Offenlegung von Schwachstellen

• 29. Juli 2025- Die Schwachstelle wurde über GitHub Security Issues gemeldet; sie wurde auch an DataStax auf HackerOne als Backup gemeldet.
• Schreiben vom 29. Juli 2025 des Ständigen Vertreters von--Langflow hat PR eingereicht #9240("Verbesserung der Cookie-Sicherheit"). Diese Front-End-Änderung hat keine Auswirkung auf das httpOnly-Cookie (das im Back-End konfiguriert werden muss), so dass sie das Problem nicht behebt.
• 31. Juli 2025- Berichte auf HackerOne sind in Kategorien eingeteilt.
• Schreiben vom 5. August 2025 des Ständigen Vertreters von-Anfrage nach einem Update zu GitHub-Sicherheitsproblemen.
• Schreiben vom 7. September 2025 des Ständigen Vertreters von-Anfrage nach einem Update zu GitHub-Sicherheitsproblemen.
• 11. September 2025- Langflow hat PR eingereicht #9441("Fügen Sie Umgebungsvariablen hinzu, um die Kontrolle durch den Benutzer zu ermöglichen") und fügte eine Warnung hinzu: "In v1.7 werden die Anmeldeinformationen automatisch deaktiviert, wenn Wildcard-Quellen verwendet werden".
• 25. September 2025-- Langflow 1.6.0 veröffentlicht: Einführung von Umgebungsvariablen zur Anpassung der erlaubten CORS-Quellen. Die Standardkonfiguration ist jedoch immer noch anfällig.
• 26. September 2025-Anfrage nach einem aktuellen Bericht über die Fortschritte von HackerOne.
• Schreiben vom 3. Oktober 2025 des Ständigen Vertreters von-- DataStax antwortete: "Es ist eine Team-Sache".
• 22. Oktober 2025- Es gibt immer noch keine Updates auf GitHub Sicherheit; VulnCheck wurde gebeten, eine CVE-Nummer zuzuweisen.
• Schreiben vom 23. Oktober 2025 des Ständigen Vertreters von--CVE-2025-34291 Die Sicherheitslücke wurde zugewiesen. Vielen Dank an das VulnCheck-Team für die schnelle CVE-Hilfe.
• 4. November 2025-Vier Monate vergingen, und da die Benutzer das Problem manuell durch Anpassung der CORS-Konfiguration entschärfen konnten, beschlossen wir, diese Studie zu veröffentlichen.

Die Sicherheitsforscher von Obsidian Security haben eine Reihe schwerwiegender Schwachstellen in Langflow entdeckt