Am 17. März 2026 veröffentlichte das Langflow-Projekt eine Sicherheitswarnung, die in der KI-Entwicklergemeinschaft sofort Alarm auslöste. Die Schwachstelle CVE-2026-33017 erlaubt es unauthentifizierten Angreifern, beliebigen Python-Code auf jedem exponierten Langflow-Server auszuführen, ohne ein Passwort, ohne ein Token, mit einem einzigen HTTP-POST-Request. Innerhalb von 20 Stunden nach der öffentlichen Disclosure starteten die ersten Angreifer koordinierte Angriffswellen. Was als Nischenproblem für KI-Entwickler erschien, entpuppte sich als kritische Bedrohung für Unternehmensinfrastruktur weltweit, auch im DACH-Raum.
Was ist Langflow: 145.000 GitHub-Stars, globale KI-Infrastruktur
Langflow ist ein Open-Source-Framework zur visuellen Erstellung von KI-Agenten und Retrieval-Augmented-Generation-Pipelines (RAG). Entwickler ziehen Komponenten per Drag-and-Drop zusammen, verbinden Sprachmodelle mit Datenbanken, APIs und Vektorspeichern und exportieren fertige Workflows als API-Endpunkte. Mit über 145.000 Sternen auf GitHub gehört Langflow zu den meistgenutzten Tools im Bereich KI-Anwendungsentwicklung.
Unternehmen aller Branchen setzen Langflow für produktive KI-Dienste ein: von Fintech-Startups bis zu Konzernen aus dem verarbeitenden Gewerbe. Die Plattform integriert sich tief in die Infrastruktur. Sie speichert API-Schlüssel für OpenAI, Anthropic und andere Modellanbieter, verbindet sich mit Produktionsdatenbanken und läuft häufig mit weitreichenden AWS- oder Azure-Berechtigungen. Genau diese Einbindung macht eine vollständige Kompromittierung eines Langflow-Servers zum Worst-Case-Szenario für die betroffene Organisation.
Besonders im DACH-Raum ist die Verbreitung erheblich. Mittelstandsunternehmen, KI-Startups und Forschungseinrichtungen nutzen Langflow für interne Chatbots, Dokumentenanalyse und automatisierte Workflows, oft ohne dediziertes Security-Team und ohne regelmäßiges Patch-Management. Diese Kombination aus breiter Verbreitung und schwacher Absicherung erklärt, warum CVE-2026-33017 innerhalb von Stunden nach der Disclosure aktiv ausgenutzt wurde.
CVE-2026-33017: Technische Details der Schwachstelle
Die Schwachstelle steckt im Endpunkt POST /api/v1/build_public_tmp/{flow_id}/flow. Dieser Endpunkt ist konzeptionell dazu gedacht, öffentliche Flows ohne Authentifizierung aufzubauen, also eine gewollte Funktion für geteilte Demos und Chatbots. Das Problem liegt im optionalen Parameter data: Statt die gespeicherten Flow-Daten aus der Datenbank zu laden, akzeptiert der Endpunkt in der verwundbaren Version beliebige Flow-Definitionen vom Angreifer, inklusive beliebigem Python-Code in den Node-Definitionen.
Dieser Code wird direkt an Pythons exec()-Funktion übergeben, ohne jegliches Sandboxing, ohne Whitelisting, ohne Eingabevalidierung. Das Ergebnis ist Remote Code Execution mit den Rechten des Langflow-Serverprozesses, typischerweise weitreichende System-Rechte. Für den Angriff braucht ein Angreifer lediglich die UUID eines öffentlichen Flows auf der Zielinstanz. Diese lässt sich aus geteilten Links oder direkten URL-Scans ermitteln.
Die Schwachstelle wurde am 26. Februar 2026 vom unabhängigen Sicherheitsforscher Aviral Srivastava entdeckt. Srivastava fand sie durch Analyse der Code-Diffs eines vorangegangenen Patches, eine Methode, die strukturell ähnliche Schwachstellen in benachbarten Code-Pfaden aufdeckt. Nach koordinierter Responsible-Disclosure-Phase erschien die öffentliche Advisory am 17. März 2026.
| Eigenschaft | Detail |
|---|---|
| CVE-Nummer | CVE-2026-33017 |
| CVSS v4.0 Score (NVD) | 9.3 (kritisch) |
| CVSS Score (JFrog) | 9.8 (kritisch) |
| Angriffsvektor | Netzwerk (AV:N) |
| Authentifizierung | Keine (PR:N, UI:N) |
| Angriffstyp | Code Injection via Python exec() |
| CWE | CWE-94 (Code Injection) |
| Betroffener Endpunkt | POST /api/v1/build_public_tmp/{flow_id}/flow |
| Betroffene Versionen | Alle Versionen vor 1.9.0 |
| Patch-Version | Langflow 1.9.0 |
| Entdeckt | 26. Februar 2026 (Aviral Srivastava) |
| Öffentliche Disclosure | 17. März 2026 |
| Erster Exploit beobachtet | ca. 20 Stunden nach Disclosure |
| CISA KEV aufgenommen | März 2026 |
| Behörden-Patch-Deadline (USA) | 8. April 2026 |
Angriffsverlauf: 20 Stunden von der Advisory bis zum ersten Exploit
Das Sysdig Threat Research Team dokumentierte den Angriffsverlauf mit forensischer Präzision. Am 17. März 2026 erschien die öffentliche Advisory für CVE-2026-33017. Kein öffentliches Proof-of-Concept war zu diesem Zeitpunkt verfügbar. Dennoch begannen Angreifer bereits rund 20 Stunden nach der Veröffentlichung mit der aktiven Ausnutzung der Schwachstelle.
“Der Zeitraum zwischen der Advisory-Veröffentlichung und dem ersten beobachteten Exploit-Versuch betrug ungefähr 20 Stunden”, stellte das Sysdig Threat Research Team in seiner Analyse fest. “Angreifer müssen keinen fertigen Exploit-Code aus einem öffentlichen Repository kopieren. Sie lesen die Advisory selbst und leiten den Angriff direkt ab, da der Mechanismus trivial verständlich ist.” Tatsächlich ist der Angriff minimal: Ein einziger HTTP-POST-Request mit einem JSON-Payload, der Python-Code in einer Node-Definition versteckt, reicht aus.
Die Forscher von Endor Labs testeten 15 Langflow-Instanzen aus dem öffentlichen Internet. Alle 15 erwiesen sich als verwundbar. Remote Code Execution war in drei unabhängigen Testläufen reproduzierbar, mit einer Erfolgsquote von 100 Prozent. Der eigentliche Exploit-Code umfasst weniger als 10 Zeilen. Die Angriffsphase verlief nach dokumentierten Beobachtungen in drei Phasen: Reconnaissance (Identifikation öffentlicher Flows), Exploitation (Ausführung beliebigen Python-Codes) und Exfiltration (Abruf gespeicherter Secrets).
Besonders alarmierend: Der Angriff erfolgte ohne jegliche Spuren in Anwendungs-Logs, da der Endpunkt by Design keine Authentifizierung erfordert und der Zugriff als legitimer öffentlicher Flow-Aufruf erscheint. Forensisch ist ein solcher Angriff ohne spezialisiertes Monitoring kaum nachweisbar.
Was Angreifer stehlen: OpenAI-Schlüssel, AWS-Credentials, Datenbankpasswörter
Sobald ein Angreifer Code auf einem Langflow-Server ausführen kann, ist der Zugriff auf alle gespeicherten Geheimnisse trivial. Das Cloud Security Alliance (CSA) Lab dokumentierte drei Hauptkategorien gestohlener Daten aus beobachteten Angriffen: API-Schlüssel für KI-Modellanbieter (primär OpenAI und Anthropic), Cloud-Provider-Credentials (hauptsächlich AWS Access Keys und Secret Keys) sowie Datenbankpasswörter für Produktionsdatenbanken, die in Langflow-Workflows eingebunden sind.
Das CSA Research Lab fasste in seiner Analyse zusammen: “CVE-2026-33017 ist Teil eines größeren, systemischen Musters unsicherer Code-Execution-Designs in Langflow. Die Plattform sammelt by Design KI-Provider-Secrets und Cloud-Credentials an einem zentralen Punkt. Ein einziger kompromittierter Server gibt Angreifern Zugang zur vollständigen KI-Infrastruktur einer Organisation.” Diese Einschätzung erklärt, warum CISA die Schwachstelle als besonders kritisch einstufte.
Endor Labs beschrieb den möglichen Schadenumfang konkret: “Der Impact umfasst unauthentifizierte Remote Code Execution mit vollständigen Server-Prozessrechten, komplette Server-Kompromittierung mit Zugriff auf beliebige Dateien und Befehle, Exfiltration von Umgebungsvariablen inklusive API-Schlüsseln, Datenbank-Credentials und Cloud-Tokens sowie Reverse-Shell-Zugang für persistenten Zugriff und laterale Bewegung im Netzwerk.”
Für DACH-Unternehmen bedeutet der Diebstahl von OpenAI- oder Anthropic-API-Schlüsseln zunächst finanzielle Schäden durch missbräuchliche Nutzung des gestohlenen API-Zugangs. Gestohlene AWS-Credentials öffnen potenziell Türen zu S3-Buckets mit Kundendaten, zu weiteren internen Services und zu ganzen Cloud-Infrastrukturen. Im Kontext der DSGVO kann ein solcher Vorfall Meldepflichten auslösen und erhebliche Bußgelder nach sich ziehen. Unter dem KRITIS-Dachgesetz 2026 verschärfen sich diese Anforderungen weiter.
Die falsche Sicherheit: Version 1.8.2 bleibt verwundbar
Einer der gravierendsten Aspekte dieser Schwachstelle ist die Diskrepanz zwischen kommuniziertem und tatsächlichem Sicherheitsstatus. Als die Advisory am 17. März erschien, behaupteten zahlreiche öffentliche Quellen, Version 1.8.2 sei bereits gepatcht. Das JFrog Security Research Team ließ dies nicht ungeprüft stehen.
JFrog-Forscher verifizierten mit einem öffentlichen Proof-of-Concept, dass Version 1.8.2 weiterhin vollständig für CVE-2026-33017 anfällig ist. Sowohl das PyPI-Paket als auch das offizielle Docker-Image von 1.8.2 blieben ausnutzbar. “Wir haben einen gefährlichen Graben zwischen wahrgenommener und tatsächlicher Sicherheit identifiziert”, schrieb das JFrog Security Research Team. “Organisationen, die nach dem Advisory sofort auf 1.8.2 upgradeten und sich sicher wähnten, waren es nicht. Die tatsächlich sichere Version ist 1.9.0.” JFrog alarmierte daraufhin die Maintainer, die den GitHub Advisory Database-Eintrag korrigierten.
Diese Situation schuf ein besonders gefährliches Zeitfenster. Sicherheitsverantwortliche, die die Empfehlung auf 1.8.2 zu upgraden befolgten, glaubten, geschützt zu sein, waren aber weiterhin exponiert. JFrog empfahl zwischenzeitlich, Langflow komplett zu deinstallieren und stattdessen den Nightly-Build zu installieren, bis 1.9.0 offiziell verfügbar war. Für DACH-Unternehmen unterstreicht dieser Vorfall die Notwendigkeit, Security-Advisories kritisch zu prüfen und sich nicht ausschließlich auf erste Patch-Empfehlungen zu verlassen.
CISA KEV: Bundesbehörden mit Patch-Deadline 8. April 2026
Die amerikanische Cybersicherheitsbehörde CISA (Cybersecurity and Infrastructure Security Agency) nahm CVE-2026-33017 innerhalb weniger Tage nach der Disclosure in den Known Exploited Vulnerabilities (KEV) Catalog auf. Der KEV Catalog listet ausschließlich Schwachstellen, für die aktive Ausnutzung in freier Wildbahn bestätigt ist. Die Aufnahme in diesen Catalog verpflichtet US-Bundesbehörden zum Patchen bis zum Stichtag: 8. April 2026.
Für DACH-Unternehmen ist die KEV-Aufnahme kein direktes regulatorisches Instrument, wohl aber ein unmissverständliches Signal: Diese Schwachstelle wird aktiv ausgenutzt, und Behörden der größten Volkswirtschaft der Welt priorisieren den Patch als Notfallmaßnahme. Unter den Rahmenbedingungen von NIS-2 und dem KRITIS-Dachgesetz 2026 sollten Betreiber kritischer Infrastrukturen Langflow-Instanzen mit dem gleichen Zeitdruck behandeln.
Langflow hatte bereits eine Vorgeschichte mit CISA: Die Schwachstelle CVE-2025-3248 aus dem Vorjahr war ebenfalls in den KEV Catalog aufgenommen worden. Damit ist Langflow eine der wenigen Open-Source-Plattformen, die innerhalb von 12 Monaten zweimal auf der KEV-Liste landete, ein historisch seltenes Ereignis, das die strukturellen Sicherheitsprobleme der Plattform verdeutlicht.
Systemisches Muster: Vierter RCE-Exploit in Langflow seit 2025
CVE-2026-33017 ist keine isolierte Schwachstelle, sondern Teil eines systemischen Musters. Seit 2025 hat Langflow mindestens vier Remote-Code-Execution-Klassen-Schwachstellen akkumuliert. Die wiederkehrende Verwendung von Pythons exec() ohne Sandboxing, fehlende Authentifizierung an öffentlich zugänglichen Endpunkten und unzureichende Eingabevalidierung ziehen sich durch die gesamte Codebase.
Das Muster erklärt sich durch die Architektur: Langflow ist ein Rapid-Development-Tool, das Flexibilität über Sicherheit stellt. Die visuelle Drag-and-Drop-Oberfläche erfordert die Fähigkeit, beliebigen Code zur Laufzeit auszuführen. Das ist by Design so, und genau diese Design-Entscheidung wird wiederholt zur Sicherheitslücke. SentinelOne formulierte die Kernproblematik direkt: “Die Schwachstelle repräsentiert einen kritischen Code-Injection-Fehler in Langflows Public-Flow-Building-Funktionalität. Das Angriffsmuster ist netzwerkbasiert und erfordert weder Authentifizierung noch Benutzerinteraktion.”
Srivastava betonte in seiner Disclosure-Dokumentation: “Ich fand CVE-2026-33017, indem ich die Code-Diffs eines vorangegangenen Patches analysierte. Das ist ein klassisches Muster: Wenn ein Fix für einen unsicheren Mechanismus unvollständig ist, bleibt derselbe Mechanismus in benachbarten Code-Pfaden häufig unangetastet. Die eigentliche Ursache ist nicht ein einmaliger Fehler, sondern eine Design-Entscheidung, die sich durch die gesamte Codebase zieht.”
| CVE | CVSS | Typ | Jahr | CISA KEV | Betroffene Version | Patch |
|---|---|---|---|---|---|---|
| CVE-2025-3248 | 9.8 | Unauthentifiziertes RCE | 2025 | Ja | Vor 1.2.0 | 1.2.0 |
| CVE-2026-33017 | 9.3 (NVD) / 9.8 (JFrog) | Code Injection via exec() | 2026 | Ja | Vor 1.9.0 | 1.9.0 |
| Weitere RCE-Klassen (2025-2026) | Variiert | exec()-basiert | 2025-2026 | Teilweise | Verschiedene | Verschiedene |
Auswirkungen auf DACH-Unternehmen: KI-Infrastruktur im Visier
Der DACH-Raum ist von CVE-2026-33017 in mehrfacher Hinsicht betroffen. Viele deutsche und österreichische KI-Projekte setzen Langflow ein, da die Plattform keine tiefen Programmierkenntnisse voraussetzt und sich ideal für Proof-of-Concept-Projekte und interne KI-Assistenten eignet. Besonders Mittelstandsunternehmen, die ohne große Sicherheitsabteilung KI-Lösungen aufbauen, betreiben Langflow häufig mit minimaler Absicherung.
Das regulatorische Umfeld im DACH-Raum verschärft die Konsequenzen zusätzlich. Das KRITIS-Dachgesetz 2026 mit Bußgeldern bis zu einer Million Euro und die NIS-2-Umsetzung in Deutschland mit Strafen bis zu zehn Millionen Euro oder zwei Prozent des weltweiten Jahresumsatzes stellen hohe Anforderungen an das Patch-Management. Ein ungepatchtes Langflow-System mit bekannter CISA-KEV-Schwachstelle wäre bei einem Vorfall gegenüber Aufsichtsbehörden kaum zu rechtfertigen.
Die Chambers-Cybersecurity-Analyse für Deutschland 2026 zeigt zudem, dass professionelle Angreifer ihre Zeitpunkte bewusst auf kritische Betriebsphasen ausrichten: Produktionsspitzen, regulatorische Meldestichtage oder M&A-Transaktionen. KI-Infrastruktur als neues Angriffsziel passt in dieses Muster. Unternehmen, die KI-Dienste produktiv einsetzen, sind auf deren Verfügbarkeit angewiesen und damit besonders erpressbar.
Patch-Strategie: Sofortmaßnahmen und mittelfristiger Schutz
Die höchste Priorität hat das Upgrade auf Langflow 1.9.0 oder eine neuere Version. Wer noch auf einer Version unter 1.9.0 läuft, muss davon ausgehen, bereits angegriffen worden zu sein, und alle gespeicherten Secrets als kompromittiert behandeln. Das bedeutet konkret: Rotation aller OpenAI-API-Schlüssel, aller Anthropic-API-Schlüssel, aller AWS-Credentials und aller Datenbankpasswörter, die in der Langflow-Instanz gespeichert oder verwendet wurden.
Endor Labs empfiehlt: “Behandeln Sie alle auf Langflow-Instanzen gespeicherten Umgebungsvariablen, inklusive API-Schlüssel, Datenbank-Credentials und Cloud-Tokens, als vollständig kompromittiert, sobald eine anfällige Version im Einsatz war.” Wer einen Angriff vermutet, sollte Cloud-Provider-Logs auf ungewöhnliche API-Aufrufe prüfen (AWS CloudTrail, Azure Activity Log) sowie Server-Logs auf POST-Requests an /api/v1/build_public_tmp/ mit ungewöhnlich großen JSON-Payloads.
Kurzfristig, falls ein sofortiges Upgrade nicht möglich ist: Netzwerkzugang zur Langflow-Instanz einschränken. Kein Langflow-Server sollte aus dem offenen Internet erreichbar sein. VPN-Zugang oder IP-Whitelisting reduzieren die Angriffsfläche erheblich. Mittelfristig sollten Organisationen bewerten, ob Langflow für sicherheitskritische Produktionsumgebungen das richtige Tool ist. Alternativen mit strikterem Sandboxing-Mechanismus bieten in produktiven Umgebungen mehr Kontrolle.
KI-Framework-Sicherheit 2026: Der breitere Kontext
CVE-2026-33017 steht nicht allein. Der März 2026 brachte mehrere schwerwiegende Schwachstellen in KI-naher Infrastruktur, was den Trend unterstreicht, dass KI-Frameworks als Angriffsziel zunehmend attraktiv werden.
Ein autonomer KI-Bot kompromittierte im März 2026 GitHub-Actions-Workflows bei Microsoft, DataDog, Aqua Security und der Cloud Native Computing Foundation (CNCF). Der Bot erreichte Remote Code Execution in fünf von sieben Zielen und löschte das Aqua-Security-Repository Trivy mit über 32.000 GitHub-Stars vollständig. Im Mai 2026 offenbarte CVE-2026-28879 eine Zero-Day-Schwachstelle in Gogs, die unauthentifizierte Remote Code Execution auf selbst gehosteten Git-Instanzen ermöglichte.
Das Muster ist deutlich: KI-Infrastruktur und Entwicklerwerkzeuge werden systematisch als Angriffsziel erschlossen. Sie verbinden drei für Angreifer attraktive Eigenschaften: breite Verbreitung in Unternehmensumgebungen, tiefe Integration in sensible Infrastruktur und historisch geringere Sicherheitsreife verglichen mit klassischen Enterprise-Softwarekategorien.
5 Prognosen: KI-Framework-Sicherheit bis Ende 2026
1. KI-Frameworks werden zum Top-3-Angriffsziel 2026. Die Kombination aus breiter Verbreitung, tiefer Integration in Unternehmensinfrastruktur und historisch schwachem Sicherheitsfokus macht KI-Frameworks attraktiver als klassische Web-Applikationen für gezielte Angriffe. Weitere kritische RCE-Schwachstellen in populären KI-Frameworks sind bis Q4 2026 zu erwarten.
2. CISA erweitert KEV-Fokus auf KI-Infrastruktur. Nach CVE-2025-3248 und CVE-2026-33017 ist Langflow zweifacher KEV-Kandidat. CISA wird seinen Scope auf KI-spezifische Frameworks ausweiten und eine dedizierte KI-Sicherheits-Guidance für Bundesbehörden herausgeben.
3. Regulatorischer Druck auf KI-Framework-Anbieter wächst im DACH-Raum. Das KRITIS-Dachgesetz und die NIS-2-Umsetzung werden dazu führen, dass Unternehmen vertragliche Sicherheitsanforderungen an Open-Source-Tools formulieren. Tools mit wiederkehrenden kritischen CVEs werden aus Compliance-Gründen in kritischen Infrastrukturen gemieden.
4. Langflow führt Sandboxing ein oder verliert Marktanteile. Der Druck durch wiederholt kritische CVEs und die CISA-KEV-Einträge wird das Langflow-Projekt zwingen, grundlegende Architekturänderungen vorzunehmen. Andernfalls werden Enterprise-Organisationen auf sichere Alternativen wechseln.
5. Secret-Scanning wird Standard für KI-Pipeline-Deployments. Die Tatsache, dass Angreifer primär API-Keys und Credentials stehlen, wird dazu führen, dass Secrets-Management-Lösungen und automatisches Secret-Scanning stärker in KI-Deployment-Pipelines integriert werden. Secrets in Umgebungsvariablen ohne Rotation werden als inakzeptables Risiko eingestuft.
Verwandte Berichterstattung auf shattered.io
- Veeam Backup RCE: CVSS 9.9, 4x auf CISA KEV [2026]
- KRITIS-Dachgesetz 2026: 1 Mio. Euro Bußgeld, 17. Juli Deadline
- NIS-2 Deutschland: 29.500 Firmen, 10 Mio. Euro Strafe
- Operation Endgame: 3 Phasen, 1.425+ Server, 21 Mio. Euro
- CrowdStrike 2026: Angriff in 27 Sekunden, KI-Attacken +89 %
- Security Pillar: Alle CVE- und Breach-Analysen
Haeufig gestellte Fragen zu CVE-2026-33017
Welche Langflow-Version behebt CVE-2026-33017 tatsaechlich?
Ausschließlich Langflow 1.9.0 behebt die Schwachstelle vollständig. Version 1.8.2 wurde zunächst fälschlicherweise als Patch kommuniziert, ist aber nach Verifikation durch JFrog Security Research weiterhin anfällig. Alle Versionen unter 1.9.0 sind verwundbar. Das Upgrade auf 1.9.0 oder höher ist die einzige sichere Mitigation.
Bin ich betroffen, wenn ich Langflow nur intern nutze?
Bedingt ja. Der verwundbare Endpunkt ist standardmäßig aktiv und erfordert nur Netzwerkzugang zur Langflow-Instanz. Interne Deployments ohne Internet-Exposure sind weniger gefährdet, aber nicht immun: Angreifer mit initialem Netzwerkzugang können die Schwachstelle zur Privilege Escalation und lateralen Bewegung nutzen. Das Upgrade auf 1.9.0 ist auch für intern betriebene Instanzen obligatorisch.
Welche Meldepflichten entstehen bei einem Langflow-Breach in Deutschland?
Unter der DSGVO gilt eine 72-Stunden-Meldepflicht an die zuständige Datenschutzbehörde, wenn personenbezogene Daten betroffen sind. Bei KRITIS-Betreibern greift zusätzlich das KRITIS-Dachgesetz mit eigenständigen Meldepflichten. Unter NIS-2 müssen erhebliche Sicherheitsvorfälle innerhalb von 24 Stunden initial und innerhalb von 72 Stunden mit einem vollständigen Bericht gemeldet werden. Konsultieren Sie umgehend Ihren Datenschutzbeauftragten und einen auf Cybersicherheitsrecht spezialisierten Anwalt.
Was bedeutet CISA KEV für deutsche Unternehmen?
Die CISA KEV ist primär ein US-Behörden-Instrument ohne direkte rechtliche Bindung für deutsche Unternehmen. Sie gilt jedoch als verlässlicher Indikator für aktive Ausnutzung in freier Wildbahn. Unter NIS-2 und dem KRITIS-Dachgesetz sollten KEV-Einträge als verbindliche Priorisierungshilfe behandelt werden: Eine KEV-gelistete Schwachstelle in eingesetzter Software verlangt sofortige Patch-Aktion.
Wie erkenne ich, ob meine Instanz bereits kompromittiert wurde?
Prüfen Sie Server-Logs auf POST-Requests an /api/v1/build_public_tmp/ mit ungewöhnlich großen JSON-Payloads. Prüfen Sie Cloud-Provider-Logs (AWS CloudTrail, Azure Activity Log) auf ungewöhnliche API-Aufrufe mit Ihren gespeicherten Credentials. Wenn nicht mit Sicherheit ausgeschlossen werden kann, dass eine anfällige Version im Einsatz war, behandeln Sie alle Secrets als kompromittiert und rotieren Sie sie sofort.
Welche sicheren Alternativen zu Langflow gibt es?
Für produktionskritische Umgebungen mit strikten Sicherheitsanforderungen bieten sich n8n (Self-hosted Workflow-Automatisierung mit strikterem Sandboxing), Apache Airflow (etablierte Workflow-Orchestrierung mit Enterprise-Sicherheitsfokus) oder direkte Python-Implementierungen mit LangChain und striktem Secrets-Management an. Für reine Prototyping-Umgebungen ohne Internet-Exposure und ohne sensible Credentials bleibt Langflow nach dem Patch auf 1.9.0 eine Option.
Externe Quellen: Sysdig Threat Research: CVE-2026-33017 | JFrog: Langflow 1.8.2 weiterhin anfällig | CSA Research Note: CVE-2026-33017 | SentinelOne Vulnerability Database | Endor Labs: CVE-2026-33017 Impact
