Betroffene Einrichtungen
Bereich
In IBM Langflow OSS (Versionen 1.0.0 bis 1.10.0 bzw. bis Commit 94981c4 in Version 1.9.2) existiert eine kritische Code-Injection-Schwachstelle in der ToolGuard-Integration der Policies-Komponente: Der Validierungsmechanismus prüft zwar den Hauptquellcode im Feld node_template["code"]["value"], lässt jedoch dynamische CodeInput-Felder, in denen generierte ToolGuard-Python-Dateien gespeichert werden, vollständig ungeprüft. Ein Angreifer kann dadurch trotz gesetzter Sicherheitsoption allow_custom_components=false beliebigen Python-Code einschleusen und mit den Rechten des Langflow-Prozesses auf dem Server ausführen, was bei einem CVSS-Score von 9.9 einer nahezu vollständigen Kompromittierung des Systems entspricht. Langflow wird als KI-Workflow-Plattform eingesetzt und könnte in Gesundheitseinrichtungen zur Automatisierung klinischer oder administrativer Prozesse – etwa in Verbindung mit KIS-Schnittstellen oder Diagnostiksystemen – betrieben werden; sofern dies der Fall ist, drohen Datenverlust, Manipulation klinischer Daten und Ausfall kritischer Anwendungen. Angesichts des kritischen Schweregrads ist eine sofortige Aktualisierung oder Abschaltung betroffener Instanzen dringend geboten.
1 Langflow OSS auf eine Version über 1.10.0 aktualisieren bzw. – sofern kein Patch verfügbar – Langflow-Instanzen sofort vom Netz nehmen; als Workaround alle dynamischen CodeInput-Felder in ToolGuard-Komponenten deaktivieren und die Validierung auf sämtliche node_template-Felder ausweiten.
2. Bestandsaufnahme aller Langflow-Deployments im Haus durchführen (on-premise sowie Cloud/SaaS-Instanzen) und prüfen, ob allow_custom_components=false gesetzt ist – dieser Schutz ist laut CVE allein nicht ausreichend.
3. Netzwerksegmentierung prüfen: Langflow-Server dürfen nicht direkt aus dem Kliniknetz oder dem KIS-Segment erreichbar sein; Zugang auf autorisierte Benutzer über VPN oder interne Firewall-Regeln beschränken.
4. Logs der Langflow-Instanzen auf ungewöhnliche Python-Codeausführungen, unbekannte Prozesse und verdächtige Netzwerkverbindungen untersuchen (Zeitraum ab Einführung der betroffenen Version 1.0.0).
5. Vorfall gemäß internem Incident-Response-Plan eskalieren; bei Hinweisen auf aktive Ausnutzung BSI (DE) bzw. BACS (CH) oder CERT.at (AT) informieren und betroffene Systeme forensisch sichern.
NIS2-Relevanz: ••• B3S: ••• ISG: ••ˆ Meldepflicht DE: ja