Viele Unternehmen erproben derzeit visuelle Plattformen für LLM-Workflows und KI-Agenten. Der Reiz liegt auf der Hand: Fachabteilungen verbinden Datenquellen, Modelle, Tools und APIs über eine Oberfläche, ohne für jeden Prototyp ein eigenes Backend aufzusetzen. Doch genau diese Bequemlichkeit verschiebt eine klassische Sicherheitsgrenze. Was früher „nur“ ein Prompt oder ein Workflow-Export war, kann heute indirekt Befehle auf einem Server auslösen, Cloud-Zugangsdaten nutzen oder interne Systeme erreichen.
Ein aktueller Fall rund um Flowise macht dieses Risiko sichtbar. Flowise ist eine Open-Source-Plattform für den visuellen Aufbau von LLM-Flows und AI Agents. Das Projekt beschreibt sich auf GitHub knapp als „Build AI Agents, Visually“ und zählt laut GitHub-API mehr als 53.000 Sterne. SecurityWeek berichtete am 30. Mai 2026, dass Exploit-Code für eine kritische Remote-Code-Execution-Schwachstelle in Flowise veröffentlicht wurde. Die Lücke läuft unter CVE-2026-40933 und hängt mit der Unterstützung des Model Context Protocol (MCP) über stdio zusammen.
Was technisch passiert
Die offizielle GitHub Security Advisory zu GHSA-c9gw-hvqq-f33r beschreibt den Kern der Schwachstelle als „Authenticated RCE Via MCP Adapters“. Betroffen waren flowise und flowise-components bis einschließlich Version 3.0.13. Als gepatchte Version nennt GitHub 3.1.0. NVD bewertet CVE-2026-40933 mit CVSS 9.9 und ordnet sie CWE-78 zu, also Command Injection. Laut Advisory konnte ein authentifizierter Angreifer über die Custom-MCP-Konfiguration einen stdio-MCP-Server mit beliebigem Kommando hinzufügen. Das Beispiel im Advisory nutzt npx mit Argumenten, um einen Befehl auf dem zugrunde liegenden Betriebssystem auszuführen.
Das ist kein exotisches Implementierungsdetail. MCP-Server dienen in Agenten-Architekturen als Brücke zu Werkzeugen, Dateien, APIs oder lokalen Programmen. Beim stdio-Transport startet die Anwendung typischerweise einen lokalen Prozess und kommuniziert mit ihm über Standard-Ein- und -Ausgabe. Für legitime Integrationen ist das praktisch. Für eine mehrmandantenfähige Webanwendung oder ein gemeinsam genutztes Agenten-Backend wird es gefährlich, wenn Nutzer kontrollieren können, welches Kommando gestartet wird.
Obsidian Security hat den Fall in einem eigenen Research-Post weiter zugespitzt. Die Forscher sprechen von einer „one-click RCE“: Ein Angreifer könne einen präparierten Chatflow exportieren und einen berechtigten Nutzer zum Import bewegen. Bereits das Rendern beziehungsweise Laden des importierten Flows könne die Tool-Auflistung auslösen und dabei das konfigurierte MCP-Kommando starten. Nach Darstellung von Obsidian reicht unter bestimmten Bedingungen also der Import eines Workflows — noch bevor der Nutzer ihn bewusst speichert oder ausführt.
Warum der Fall für Unternehmen relevant ist
Der praktische Schaden hängt nicht davon ab, ob auf dem Flowise-Server ein besonders interessantes Betriebssystem läuft. Entscheidend ist, worauf die Agenten-Plattform Zugriff hat. In produktiven Setups sind solche Werkzeuge häufig mit Datenbanken, SaaS-APIs, Ticket-Systemen, Dokumentenablagen, Cloud-Accounts, Vektordatenbanken oder internen HTTP-Endpunkten verbunden. Läuft Code mit den Rechten des Flowise-Prozesses, werden gespeicherte Credentials, Umgebungsvariablen und Netzwerkreichweite zum eigentlichen Risiko.
SecurityWeek zitiert Obsidian mit der Einschätzung, dass eine erfolgreiche Ausnutzung OS-Level-Codeausführung mit den Rechten des Flowise-Prozesses ermöglichen kann — in Container-Setups häufig mit weitreichenden Rechten innerhalb des Containers. Obsidian weist zudem darauf hin, dass Flowise Cloud nach eigener Analyse nicht betroffen sei, weil stdio MCP dort deaktiviert ist. Selbst gehostete Open-Source- und Enterprise-Deployments seien dagegen standardmäßig verwundbar, sofern die betroffenen Funktionen aktiv sind.
Wichtig ist die Einordnung: CVE-2026-40933 erfordert laut GitHub/NVD Authentifizierung beziehungsweise niedrige Privilegien. Es handelt sich also nicht um eine beliebige Internet-RCE gegen jedes öffentlich erreichbare Flowise-System. Das Risiko bleibt dennoch hoch, weil „authentifizierter Nutzer“ in Agenten-Tools oft ein breiter Kreis ist: Entwickler, Data-Science-Teams, Power-User aus Fachbereichen, externe Integratoren oder kompromittierte Konten. Hinzu kommt die von Obsidian beschriebene Variante, bei der Social Engineering über einen importierten Workflow die Hürde weiter senkt.
Die größere Lehre: Agenten-Workflows sind Supply Chain
Der Fall folgt einem Muster, das klassische Application Security nur teilweise abdeckt. Ein Workflow-Export ist nicht mehr bloß Konfiguration. Er kann Prompts, Tool-Definitionen, Credential-Referenzen, Modellparameter und Ausführungslogik enthalten. Damit ähnelt er eher einem Build-Skript oder einer CI/CD-Pipeline als einer harmlosen JSON-Datei.
Genau deshalb sind Importfunktionen in Agenten-Plattformen kritisch. Unternehmen sollten importierte Chatflows, Agenten-Templates, MCP-Konfigurationen und Community-Beispiele wie Software-Supply-Chain-Artefakte behandeln. Wer einen Workflow aus einem Blogpost, einer Demo, einem Repository oder von einem Dienstleister übernimmt, importiert potenziell ausführbare Infrastruktur-Logik. In der Praxis braucht es dafür dieselben Kontrollen wie bei Terraform-Modulen, GitHub Actions, npm-Paketen oder Dockerfiles: Review, Herkunftsprüfung, minimale Rechte und eine isolierte Testumgebung.
Auch die Debatte um MCP wird dadurch konkreter. Das Protokoll ist nicht automatisch „unsicher“, nur weil ein Transport Prozesse starten kann. Plattformen müssen aber klar trennen, ob MCP-Server zentral administriert, benutzerspezifisch konfiguriert oder frei aus importierten Artefakten geladen werden dürfen. Ein sicherer Enterprise-Standard wäre: Administratoren geben erlaubte MCP-Server frei, Parameter werden per Allowlist validiert, stdio ist in Mehrbenutzer- oder Cloud-Umgebungen standardmäßig deaktiviert, und jeder Tool-Aufruf wird protokolliert.
Konkrete Maßnahmen
Für Unternehmen mit Flowise-Installationen beginnt die Arbeit mit einem sauberen Asset-Check: Wo läuft Flowise selbst gehostet, welche Version ist installiert, ist MCP aktiviert, und welche Nutzer dürfen Chatflows erstellen oder importieren? Systeme bis Version 3.0.13 sollten mindestens auf 3.1.0 aktualisiert werden, wie GitHub es für GHSA-c9gw-hvqq-f33r ausweist. Gleichzeitig sollten Betreiber die von Obsidian beschriebene Kritik ernst nehmen: Wenn stdio für den eigenen Use Case nicht zwingend erforderlich ist, ist Deaktivierung robuster als reine Eingabevalidierung. Obsidian nennt dafür die Konfiguration CUSTOM_MCP_PROTOCOL=sse als pragmatische Härtungsoption.
Zweitens sollten Agenten-Server nicht mit pauschalen Cloud- oder Datenbankrechten laufen. Secrets gehören in einen Secret Manager, nicht dauerhaft in Klartext-Umgebungsvariablen. Ausgehende Netzwerkverbindungen sollten begrenzt werden. Container sollten ohne unnötige Privilegien laufen. Docker-Socket-Mounts, Host-Dateisystem-Mounts und breite IAM-Rollen sind in diesem Kontext besonders riskant.
Drittens braucht der Importprozess Governance. Sinnvoll sind mindestens ein Vier-Augen-Review für externe Workflows, automatische Prüfungen auf MCP-stdio, Shell-Kommandos, Paketmanager-Aufrufe und verdächtige URLs sowie getrennte Staging-Instanzen. Für produktive Agenten-Flows sollte nachvollziehbar sein, wer welche Version freigegeben hat und welche Tools mit welchen Berechtigungen genutzt werden.
Fazit
CVE-2026-40933 ist mehr als eine einzelne Flowise-Lücke. Der Fall zeigt, dass Agenten-Plattformen zu einer neuen Ausführungsschicht im Unternehmen werden. Sobald Workflows Tools starten dürfen, sind sie nicht mehr nur Prompt-Engineering, sondern Teil der produktiven Angriffsfläche. Die Antwort darauf ist nicht, MCP oder Agenten pauschal zu meiden. Unternehmen sollten Agenten-Infrastruktur wie jede andere kritische Automatisierungsplattform behandeln: patchen, isolieren, Rechte minimieren, Imports prüfen und gefährliche Ausführungspfade standardmäßig abschalten.
Quellen: GitHub Security Advisory GHSA-c9gw-hvqq-f33r, NVD CVE-2026-40933, Obsidian Security Research „1-Click RCE in Flowise“, SecurityWeek-Bericht vom 30. Mai 2026.
