Flowise unter aktiver Ausnutzung: Kritische RCE-Lücke CVE-2025-59528 bedroht über 12.000 Instanzen

Flowise steht erneut im Fokus der Sicherheitsszene: Laut einer aktuellen Meldung von The Hacker News unter Berufung auf VulnCheck wird die kritische Schwachstelle CVE-2025-59528 aktiv angegriffen. Für Unternehmen, die Flowise als Baukasten für AI-Agenten, LLM-Workflows oder MCP-Integrationen einsetzen, ist das keine rein theoretische Warnung mehr, sondern ein akutes Betriebsrisiko.

Im Kern geht es um eine Remote-Code-Execution-Lücke im CustomMCP-Node von Flowise. Die Schwachstelle betrifft laut NVD Flowise 3.0.5 und wurde in Version 3.0.6 behoben. Brisant ist der Fall nicht nur wegen des CVSS-Scores von 10.0, sondern auch wegen des betroffenen Einsatzbereichs: Wer Agenten-Plattformen mit Tool-Zugriffen, Dateisystemnähe und externen MCP-Servern betreibt, öffnet im Ernstfall nicht nur eine einzelne Anwendung, sondern oft gleich mehrere operative Vertrauensgrenzen.

Was bei CVE-2025-59528 technisch schiefläuft

Nach Angaben der GitHub Advisory Database und der NVD verarbeitet der CustomMCP-Node benutzerkontrollierte Konfigurationen für externe MCP-Server unsicher. Dabei wird die Eingabe nicht nur geparst, sondern als JavaScript ausgewertet. Genau das macht aus einer fehlerhaften Konfigurationsverarbeitung eine ausgewachsene RCE-Lücke.

Das Problem ist für AI-Agent-Umgebungen besonders heikel, weil solche Plattformen oft mit weitreichenden Laufzeitrechten betrieben werden. Wenn angreifbarer Anwendungscode innerhalb einer Node.js-Laufzeit auf Module wie child_process oder fs zugreifen kann, geht es schnell nicht mehr nur um einen Agent-Workflow, sondern um Shell-Zugriffe, Dateisystemzugriffe, Geheimnisse im Klartext und mögliche Seiteneffekte auf angrenzende Services.

Screenshot: Beispiel Flowise-Node-Setup mit verschiedenen Nodes.

Wer das Thema vertiefen möchte, findet hier bereits passende Grundlagen zu Unexpected Code Execution und zu MCP Security und Tool-Trust-Boundaries.

Eng verwandt sind außerdem unsere Threat-Analysen zu Tool Misuse and Exploitation, wenn Agenten oder Builder sensible Funktionen missbrauchen können, sowie zu Identity and Privilege Abuse, sobald weitreichende Tokens, Service-Accounts oder unklare Rechtepfade im Spiel sind.

Warum die aktive Ausnutzung jetzt so relevant ist

Die eigentliche Warnung am 7. April 2026 ist nicht die bloße Existenz der CVE. Die Schwachstelle wurde bereits im September 2025 öffentlich dokumentiert und gepatcht. Neu ist laut The Hacker News die Beobachtung aktiver Ausnutzungsversuche im Internet. Zusätzlich verweist der Bericht auf mehr als 12.000 exponierte Flowise-Instanzen, was die operative Relevanz deutlich erhöht.

Für Security-Teams ist das ein typisches Muster mit hohem Druck:

• eine kritische Lücke ist seit Monaten bekannt
• es gibt einen verfügbaren Fix
• viele Instanzen sind weiterhin öffentlich erreichbar
• jetzt beginnt oder beschleunigt sich die reale Ausnutzung

Sobald dieser Punkt erreicht ist, verschiebt sich die Priorität von geplanter Wartung zu Incident-Prävention. Dann reicht es nicht mehr, die Schwachstelle in den nächsten Sprint zu schieben. Internet-exponierte Flowise-Systeme sollten in diesem Stadium wie aktiv gefährdete Systeme behandelt werden.

Flowise ist nicht zum ersten Mal betroffen

Der aktuelle Fall wirkt auch deshalb schwerer, weil CVE-2025-59528 laut The Hacker News bereits die dritte Flowise-Schwachstelle mit beobachteter Ausnutzung in freier Wildbahn ist. Genannt werden außerdem:

• CVE-2025-8943, eine kritische OS-Command-RCE rund um Custom-MCP-Funktionalität
• CVE-2025-26319, eine Schwachstelle für beliebigen Dateiupload

Für Betreiber bedeutet das: Das Risiko liegt nicht nur in einer einzelnen fehlerhaften Funktion, sondern im generellen Spannungsfeld zwischen Agenten-Orchestrierung, Tool-Ausführung, Dateizugriff und schwachen Vertrauensgrenzen. Genau deshalb sollten Teams Flowise nicht wie ein harmloses UI-Tool behandeln, sondern wie eine sicherheitsrelevante Orchestrierungsplattform.

Was Unternehmen jetzt konkret tun sollten

Die erste Maßnahme ist banal, aber entscheidend: Flowise auf eine gepatchte Version anheben. Für CVE-2025-59528 ist das laut Advisory mindestens 3.0.6. Wer noch ältere oder individuell angepasste Deployments betreibt, sollte zusätzlich prüfen, ob Container-Images, Helm-Charts, Self-Hosted-Templates oder interne Baselines tatsächlich auf den gefixten Stand gezogen wurden.

Danach sollte die Umgebung selbst überprüft werden:

• Ist die Flowise-Instanz direkt aus dem Internet erreichbar?
• Ist die Nutzung des CustomMCP-Nodes überhaupt erforderlich?
• Welche Tokens, Secrets und Dateisystempfade sind für den Dienst erreichbar?
• Gibt es Telemetrie für verdächtige Prozessstarts, neue Child-Processes oder ungewöhnliche Dateioperationen?
• Sind API-Tokens breit verteilt oder in Automationen hart verdrahtet?

Zusätzlich lohnt sich ein Blick auf grundlegende Kontrollen wie Least Privilege und Tool Security, Multi-Agent Security und Monitoring und Observability. Gerade bei Agenten-Plattformen entscheidet nicht nur der Patch über das Restrisiko, sondern auch die Frage, wie eng Laufzeitrechte, Netzpfade und Tool-Aufrufe begrenzt sind.

Wenn Flowise in produktiven oder internetnahen Umgebungen läuft, sind zusätzlich AI Sandboxing und Security Quality Assurance and Testing relevant. Sie helfen dabei, riskante Ausführungspfade vor der Freigabe enger zu begrenzen und gefährliche Seiteneffekte in Agenten-Workflows früher sichtbar zu machen.

Warum MCP-Integrationen ein eigenes Sicherheitsmodell brauchen

Der Fall zeigt sehr deutlich, warum MCP nicht nur ein Integrationsstandard, sondern auch eine zusätzliche Angriffsfläche ist. Sobald Agenten oder Agent-Builder externe Tools, lokale Prozesse oder Server-Konfigurationen dynamisch einbinden, verschiebt sich das Risiko weg von reiner Prompt-Sicherheit hin zu echter Laufzeit- und System-Sicherheit.

In der Praxis heißt das:

• MCP- und Tool-Konfigurationen brauchen strikte Validierung
• Agenten sollten nicht mit unnötigen Host-Rechten laufen
• sensible Integrationen gehören hinter klare Freigabe- und Identitätsgrenzen
• internetexponierte Management- oder Builder-Oberflächen sind besonders kritisch

Wer AI-Agenten produktiv betreibt, sollte solche Plattformen deshalb wie administrative Kontrollschichten behandeln und nicht wie isolierte Experimentierumgebungen.

Aus Bedrohungssicht ist der Flowise-Fall außerdem ein gutes Beispiel dafür, wie sich Insecure Inter-Agent Communication und schwach abgesicherte Tool-Schnittstellen gegenseitig verstärken können. Auf Kontrollseite passt dazu Input Validation and Prompt Injection Defense, weil dynamische Konfigurationspfade, externe Eingaben und Tool-Parameter nicht erst auf Runtime-Ebene Vertrauen bekommen sollten.

Einordnung für AI Agent Security

CVE-2025-59528 ist mehr als ein weiterer RCE-Eintrag in einer CVE-Liste. Die Schwachstelle verbindet drei Dinge, die in der Praxis oft unterschätzt werden: agentische Tool-Orchestrierung, schwach abgesicherte Konfigurationspfade und hohe Laufzeitprivilegien. Genau diese Kombination macht Incidents in AI-Agent-Stacks so teuer.

Die wichtigste Lehre aus dem Flowise-Fall ist deshalb nicht nur “patchen”, sondern “Agent-Plattformen als privilegierte Infrastruktur behandeln”. Wer AI-Agenten baut oder betreibt, sollte MCP-Server, Tool-Nodes, API-Tokens, Dateisystemrechte und Netzwerkpfade als Teil derselben Angriffsoberfläche modellieren.

Quellen

• The Hacker News: Flowise AI Agent Builder Under Active CVSS 10.0 RCE Exploitation; 12,000+ Instances Exposed
• NVD: CVE-2025-59528
• GitHub Advisory Database: GHSA-3gcm-f6qx-ff7p
• GitLab Advisory: CVE-2025-8943
• GitLab Advisory: CVE-2025-26319