Im Maschinenraum der KI-Baukästen gibt es diese Fächer, in die man sehr ordentlich seine kleinen Flows legt. Eigener Schlüssel, eigenes Fach, eigener Laufzettel. So steht es jedenfalls auf dem inneren Amtsblatt der Software, gleich neben dem Kaffeeautomaten, der seit Dienstag nur noch mit Warnhinweisen schäumt.
Bei Langflow hat nun ausgerechnet dieser Laufzettel geklemmt. CISA hat CVE-2026-55255 am 7. Juli 2026 in den Known Exploited Vulnerabilities Catalog aufgenommen. Der kurze Kern: Eine authentifizierte Person konnte beim Endpoint /api/v1/responses eine fremde Flow-ID angeben und damit einen Flow ausführen, der ihr nicht gehörte. Nicht Zauberei. Nur ein Seitenschlitz, der den Besitzerzettel nicht ordentlich las.
Der falsche Zettel passt trotzdem
GitHub beschreibt die Schwachstelle als Insecure Direct Object Reference: Die Hilfsfunktion get_flow_by_id_or_endpoint_name prüfte beim Zugriff über UUID nicht sauber, ob der angemeldete Benutzer auch wirklich Eigentümer des Flow-Objekts ist. Beim Zugriff über einen Endpoint-Namen gab es eine Benutzerprüfung, bei der UUID-Abzweigung aber nicht in derselben Strenge. Das ist ungefähr so, als würde die Werkstatt am Namensschild kontrollieren, beim Nummernzettel aber nur höflich nicken.
Die Bewertung ist entsprechend ungemütlich: GitHub führt die Advisory unter GHSA-qrpv-q767-xqq2, CVSS 3.1 mit 9.9, CWE-639. Betroffen ist das pip-Paket langflow in Versionen vor 1.9.1; als gepatchte Version nennt GitHub 1.9.1. CISA formuliert es knapper und härter: autorisierter Angreifer, fremde Flow-ID, fremder Flow läuft.
Warum das mehr ist als ein hübscher Baukastenkratzer
Langflow ist genau diese Sorte Werkzeug, die in Firmen gern erst als Experiment auf dem Nebenserver landet und dann plötzlich an Daten, APIs, Prompts, Schlüsseln und halben Geschäftsprozessen nuckelt. Wenn so ein System fremde Flows ausführen lässt, ist das kein dekorativer Lackschaden. Es betrifft Mandantentrennung, Ressourcenkontrolle und möglicherweise auch Daten, die durch solche Flows laufen. Der Roboter greift nicht nur in die falsche Kiste; er startet auch noch das Band.
Wichtig ist die Grenze: Die Quellen sprechen hier von einem authentifizierten Angreifer. Also nicht vom anonymen Gespenst vor dem Gartentor. Aber in Mehrbenutzer-Installationen ist genau diese Grenze oft die dünne Blechkante zwischen „Kollege darf seinen Flow starten“ und „Kollege darf meinen Flow starten“. Und dünne Blechkanten schneiden bekanntlich am besten, wenn jemand behauptet, sie seien nur theoretisch.
Was jetzt in den Wartungswagen gehört
Die nüchterne Empfehlung ist kurz: Langflow-Installationen prüfen, auf mindestens 1.9.1 bringen, exponierte oder gemeinsam genutzte Instanzen besonders anschauen, Logs rund um ungewöhnliche Flow-Ausführungen nicht wegwischen wie Sägespäne. CISA setzt für betroffene Bundesstellen im KEV-Eintrag eine Frist bis 10. Juli 2026; für alle anderen ist das kein Gesetzesgong, aber ein sehr lautes Werkstattglöckchen.
Die eigentliche Lehre ist die alte, beleidigte: KI-Werkzeuge sind keine Ausnahme von Zugriffskontrolle, nur weil sie hübsch mit Knoten und Pfeilen malen. Jeder Flow ist ein Objekt. Jeder Objektzugriff braucht Besitzprüfung. Und wenn der Automat fremde Laufzettel annimmt, hilft kein neuer Lack. Dann muss der Seitenschlitz zugeschweißt werden.
Schreibe einen Kommentar