CVE-2026-33017: Kritische Langflow-Schwachstelle in 20 Stunden ausgenutzt – CISA schlägt Alarm

KI-Infrastruktur im Fadenkreuz: Wenn 20 Stunden über die Sicherheit entscheiden

Die Geschwindigkeit, mit der Angreifer heute Schwachstellen ausnutzen, hat ein neues Niveau erreicht. Am 17. März 2026 veröffentlichte das Langflow-Projekt ein Advisory zu CVE-2026-33017 – einer kritischen Sicherheitslücke mit einem CVSS-Score von 9.3. Keine 20 Stunden später beobachtete das Cloud-Security-Unternehmen Sysdig die ersten aktiven Exploitation-Versuche im Internet. Kein öffentlicher Proof-of-Concept-Code war nötig: Die Angreifer bauten sich funktionierende Exploits direkt aus der Advisory-Beschreibung zusammen und begannen systematisch, das Internet nach verwundbaren Instanzen abzusuchen.

Am 25. März 2026 reagierte die US-Behörde CISA und nahm CVE-2026-33017 in ihren Known Exploited Vulnerabilities (KEV)-Katalog auf – ein klares Signal, dass diese Schwachstelle nicht nur theoretisch gefährlich ist, sondern aktiv für Angriffe genutzt wird. Für US-Bundesbehörden gilt eine Patch-Frist bis zum 8. April 2026. Doch auch europäische und deutsche Unternehmen, die Langflow in ihrer KI-Infrastruktur einsetzen, sollten jetzt handeln.

Was ist Langflow – und warum ist es relevant?

Langflow ist eine populäre Open-Source-Plattform zur visuellen Erstellung von KI-Pipelines und -Workflows. Entwickler und Unternehmen nutzen sie, um Large-Language-Model-Anwendungen (LLM) zu bauen, zu testen und zu deployen – von Chatbots über RAG-Systeme (Retrieval-Augmented Generation) bis hin zu komplexen Automatisierungsketten. Die Plattform hat in den vergangenen Monaten erheblich an Popularität gewonnen, insbesondere im Umfeld von Unternehmen, die ihre KI-Strategie vorantreiben.

Genau diese Verbreitung macht die Schwachstelle so brisant: Wer Langflow produktiv einsetzt, exponiert möglicherweise eine Angriffsfläche, die direkte Codeausführung auf dem Server ermöglicht – ohne Authentifizierung.

Technische Analyse: So funktioniert der Angriff

Die Schwachstelle liegt im API-Endpunkt POST /api/v1/build_public_tmp/{flow_id}/flow, der zum Bauen öffentlicher Flows vorgesehen ist. Das Problem: Dieser Endpunkt erfordert keine Authentifizierung. Schlimmer noch: Wenn ein Angreifer den optionalen data-Parameter mitsendet, verwendet der Endpunkt die vom Angreifer kontrollierten Flow-Daten anstelle der in der Datenbank gespeicherten.

Diese vom Angreifer eingeschleusten Daten können beliebigen Python-Code in Node-Definitionen enthalten. Der Code wird anschließend über die Python-Funktion exec() ausgeführt – ohne jegliche Sandbox, ohne Einschränkungen, ohne Validierung. Das Ergebnis ist eine vollständige unauthentifizierte Remote Code Execution (RCE).

Technisch betrachtet handelt es sich um eine Kombination aus zwei Schwächen:

Fehlende Authentifizierung: Der Endpunkt ist für jeden erreichbar, der Netzwerkzugriff auf die Langflow-Instanz hat. In vielen Deployment-Szenarien – insbesondere in Cloud-Umgebungen – bedeutet das: für jeden im Internet.

Unsichere Code-Ausführung: Die Verwendung von exec() ohne Sandboxing für benutzergesteuerte Eingaben ist eine der klassischsten und gefährlichsten Schwachstellen in der Softwareentwicklung. Sie ermöglicht Angreifern, beliebige Systembefehle auszuführen, Dateien zu lesen und zu schreiben sowie sich lateral im Netzwerk auszubreiten.

Ein Muster, das sich wiederholt

Bemerkenswert: CVE-2026-33017 ist nicht das erste Mal, dass Langflow durch unsichere Nutzung von exec() auffällt. Bereits CVE-2025-3248 betraf einen anderen Endpunkt (/api/v1/validate/code) mit dem gleichen grundlegenden Problem. Dass dieselbe Schwachstellenklasse erneut auftritt, wirft Fragen über die Sicherheitskultur im Entwicklungsprozess auf – und sollte Unternehmen nachdenklich stimmen, die solche Tools ohne gründliche Sicherheitsbewertung in Produktion nehmen.

Warum 20 Stunden alles verändern

Die Tatsache, dass Angreifer innerhalb von nur 20 Stunden nach der Advisory-Veröffentlichung funktionierende Exploits entwickelten, unterstreicht einen Trend, den wir bei pleXtec seit Monaten beobachten: Das Exploitation Window – die Zeitspanne zwischen Bekanntwerden einer Schwachstelle und ihrer aktiven Ausnutzung – schrumpft dramatisch.

Für IT-Teams bedeutet das: Klassische Patch-Zyklen von Wochen oder Monaten sind bei kritischen Schwachstellen keine Option mehr. Wer am Mittwoch ein Advisory liest und die Behebung für den nächsten Sprint plant, hat möglicherweise am Donnerstagmorgen bereits kompromittierte Systeme.

In diesem Fall kam erschwerend hinzu, dass kein öffentlicher PoC-Code existierte. Die Angreifer waren technisch versiert genug, den Exploit allein aus der Schwachstellenbeschreibung zu rekonstruieren. Das deutet auf organisierte, professionelle Angreifergruppen hin – nicht auf Gelegenheitshacker.

Betroffene Versionen und Abhilfe

Betroffen sind alle Langflow-Versionen bis einschließlich 1.8.1. Der Fix ist in Version 1.9.0 enthalten. Unternehmen, die Langflow einsetzen, sollten folgende Maßnahmen umgehend umsetzen:

1. Sofortiges Update auf Version 1.9.0 oder höher. Dies ist die einzige vollständige Behebung der Schwachstelle. Prüfen Sie alle Deployment-Umgebungen – Entwicklung, Staging und Produktion.

2. Netzwerkzugriff einschränken. Langflow-Instanzen sollten niemals ohne vorgeschaltete Authentifizierung und Netzwerksegmentierung direkt aus dem Internet erreichbar sein. Implementieren Sie Reverse Proxies mit Authentifizierung, VPN-Zugang oder Zero-Trust-Network-Access.

3. Forensische Prüfung durchführen. Wenn Ihre Langflow-Instanz vor dem Patch öffentlich erreichbar war, sollten Sie davon ausgehen, dass sie möglicherweise kompromittiert wurde. Prüfen Sie Serverprotokolle auf verdächtige POST-Requests an den betroffenen Endpunkt, überprüfen Sie laufende Prozesse und Netzwerkverbindungen, und kontrollieren Sie, ob neue Dateien angelegt oder Konfigurationen verändert wurden.

4. KI-Toolstack inventarisieren. Viele Unternehmen haben keinen vollständigen Überblick darüber, welche KI-Tools und -Frameworks in ihrer Infrastruktur laufen. Erstellen Sie ein aktuelles Inventar aller KI-bezogenen Softwarekomponenten und integrieren Sie diese in Ihr Schwachstellenmanagement.

Das größere Bild: KI-Infrastruktur als Angriffsfläche

CVE-2026-33017 ist kein Einzelfall. Die zunehmende Verbreitung von KI-Tools in Unternehmen schafft neue Angriffsflächen, die von klassischen Security-Programmen oft nicht abgedeckt werden. Langflow, LangChain, n8n, Flowise und ähnliche Plattformen werden häufig von Entwicklerteams eigenständig deployt – an der IT-Sicherheit vorbei, ohne Sicherheitsbewertung und ohne Monitoring.

Für IT-Verantwortliche und CISOs im Mittelstand ergibt sich daraus eine klare Handlungsaufforderung: Die KI-Strategie eines Unternehmens muss von Anfang an Sicherheitsaspekte berücksichtigen. Jedes KI-Tool, das Netzwerkzugriff hat oder Daten verarbeitet, gehört in den Scope des Sicherheitsmanagements.

Auch regulatorisch gewinnt dieses Thema an Gewicht. Der EU AI Act, dessen zentrale Bestimmungen am 2. August 2026 in Kraft treten, fordert von Unternehmen transparente und sichere KI-Systeme. Wer KI-Plattformen mit bekannten, ungepatchten Schwachstellen betreibt, riskiert nicht nur Sicherheitsvorfälle, sondern perspektivisch auch Compliance-Verstöße.

Fazit: Geschwindigkeit entscheidet

CVE-2026-33017 zeigt exemplarisch, wie schnell KI-Infrastruktur vom Innovationswerkzeug zum Einfallstor werden kann. 20 Stunden – das war die gesamte Zeitspanne, die Angreifern genügte, um aus einem Advisory einen funktionierenden Angriff zu machen. Unternehmen, die KI-Tools einsetzen, müssen diese mit derselben Sorgfalt absichern, überwachen und patchen wie jede andere kritische Infrastrukturkomponente.

Sie sind unsicher, ob Ihre KI-Infrastruktur ausreichend abgesichert ist? Unser Team unterstützt Sie bei der Sicherheitsbewertung und der Integration von KI-Plattformen in Ihr bestehendes Sicherheitskonzept. Sprechen Sie uns an – bevor die nächsten 20 Stunden beginnen.