Eine neue, schwerwiegende Sicherheitslücke in Ruflo sorgt für ernsthafte Warnungen in der Community: Mit der Ruflo MCP-Schwachstelle konnten Angreifer ohne Authentifizierung Befehle ausführen, sich Zugriff auf sensible Daten verschaffen und die persistente KI-Erinnerung (AI-Memory) gezielt beeinflussen. Der Fehler ist als CVE-2026-59726 dokumentiert und erreicht die Höchstbewertung CVSS 10.0.
Der Knackpunkt liegt nicht in der Logik einzelner Modelle, sondern in der Art, wie ein MCP-Bridge-Zugang (Model Context Protocol) in der Standardbereitstellung ins Netzwerk gestellt wurde. Das macht den Fall besonders relevant für Betreiber, die Ruflo in einer Container-Umgebung mit öffentlich erreichbaren Ports betreiben.
Was ist Ruflo und warum ist die MCP-Bridge kritisch?
Ruflo ist eine Open-Source-Plattform für die Orchestrierung von KI-Agenten. Als Multi-Agent-Umgebung unterstützt sie das Zusammenwirken mehrerer Akteure, das Koordinieren autonomer Workflows sowie den Aufbau konversationeller KI-Systeme. Je nach Deployment wird Ruflo dabei über verschiedene Komponenten und Tools erweitert.
Im Zentrum der Sicherheitsbetrachtung steht die MCP-Bridge: Über sie werden Tools bereitgestellt, die unter anderem Shell-Befehle, Datenbankoperationen, Agentenmanagement und Speicherfunktionen umfassen. In der betroffenen Konfiguration wurde dieser Tool-Zugriff per MCP standardmäßig so exponiert, dass Angreifer ihn ohne Login erreichen konnten.
Die Ruflo MCP-Schwachstelle im Detail: CVE-2026-59726
Die Ruflo MCP-Schwachstelle betrifft alle Versionen von Ruflo vor 3.16.3. Die Sicherheitsforscher haben dem Problem außerdem den Codenamen RufRoot gegeben.
Laut den vorliegenden Informationen wurde in der Standard-docker-compose.yml-Konfiguration der Port für die MCP-Bridge auf 0.0.0.0 gebunden. Dadurch ist die Bridge nicht nur lokal erreichbar, sondern über alle Netzwerk-Schnittstellen. Ob ein konkreter Angriff gelingt, hängt zwar von Firewall-Regeln, Security Groups und Netzwerksegmentierung ab. Für jede Instanz, die erreichbar ist, gilt jedoch: Der Angriff ist ohne Authentifizierung möglich.
Wie der Angriff praktisch startet
Im beschriebenen Szenario genügte ein einzelner nicht authentifizierter HTTP-POST an den Port 3001, um eine Tools-Ausführung auszulösen. Konkret war der Endpunkt /mcp der Einstiegspunkt, über den der Funktionsaufruf tools/call angestoßen werden konnte.
Über diesen Mechanismus konnte die Funktion terminal_execute aufgerufen werden. Dadurch konnten Angreifer eine vollständige Remote Code Execution innerhalb der Bridge-Containerumgebung erreichen. Der Sicherheitsbericht nennt als mögliches Beispiel das Ausführen von Kommandos wie id und das Abfragen des Hostnamens.
Vom Befehlszugriff zum Vollangriff: API-Keys und Datenabfluss
Ein wichtiger Aspekt der Ruflo MCP-Schwachstelle ist die „Kaskade“: Der anfängliche Befehlszugriff ist nicht das Endziel, sondern ein Sprungbrett. Sobald Angreifer die Umgebung kontrollierten, konnten sie tiefer greifen.
Aus dem beschriebenen Ablauf folgt, dass Angreifer:
- die API-Keys auslesen konnten, die Ruflo benötigt, um mit LLM-Anbietern zu kommunizieren,
- Benutzerkonversationen abrufen konnten, sofern diese auf der Plattform gespeichert waren,
- das System so manipulieren konnten, dass die KI-Ergebnisse künftig beeinflusst werden.
Damit wird klar: Selbst wenn das erste Eindringen „nur“ wie ein Container-Problem wirkt, kann es sich schnell zu einem vollständigen Kompromiss entwickeln – insbesondere, weil die gestohlenen Credentials dafür sorgen, dass der Angreifer weiterhin im Namen der betroffenen Plattform handeln kann.
AI-Memory Poisoning: Persistente Manipulation der KI
Besonders gefährlich ist die Möglichkeit des AI-Memory Poisoning. Der Bericht beschreibt, dass Angreifer nicht nur kurzfristig ausführen konnten, sondern auch persistente Muster in der Lernspeicher-Struktur der Plattform verändern konnten.
In der Folge kann die KI auf Basis dieser manipulierten Informationen weiterhin falsche oder gesteuerte Antworten liefern – selbst nachdem der ursprüngliche Zugriff beendet wurde. Noma Labs weist darauf hin, dass das Schreiben bösartiger Anweisungen in eine persistente KI-Erinnerung die Antworten beeinflussen kann, die zukünftige Nutzer erhalten.
In diesem Kontext werden auch die Endpunkte und Abläufe erwähnt, die vor dem Fix ohne Authentifizierung genutzt werden konnten: Der beschriebene Zugriff umfasste POST /mcp sowie POST /mcp/:group, womit Angreifer in der Bridge-Containerumgebung eine Shell erhalten, Provider-API-Keys lesen und Muster für den Agent-Lernspeicher injizieren konnten.
Warum ist das so ernst? Eine einzelne Anfrage kann reichen
Der Bericht betont, dass sich der Angriff sehr effizient anstoßen ließ: Eine einzelne nicht authentifizierte Netzwerkaktion am exponierten Port konnte zu Remote Code Execution führen. Das bedeutet in der Praxis, dass gefährdete Deployments nicht erst „lange unter Beobachtung“ stehen müssen, damit Schaden entsteht.
Wenn zudem ein Betrieb ohne restriktive Netzwerksperren erfolgt, steigt das Risiko massiv. Gerade deshalb gilt: Auch vermeintlich „kleine“ Standardfehler in Container-Konfigurationen können sich zu kritischen Sicherheitslücken entwickeln.
Fix und Gegenmaßnahmen: Was Betreiber jetzt tun sollten
Nach verantwortungsvoller Offenlegung am 30. Juni 2026 wurde die Korrektur durch den Maintainer Reuven Cohen innerhalb von 24 Stunden bereitgestellt. Die Patch-Änderungen zielen auf mehrere Schwachstellenebenen gleichzeitig.
Zu den beschriebenen Maßnahmen gehören unter anderem:
- Die MCP-Bridge wird standardmäßig nur noch an die Loopback-Schnittstelle gebunden, statt an alle Interfaces.
- Die Funktion terminal_execute wird serverseitig durch executeTool-Kontrollen abgesichert.
- MongoDB-Authentifizierung wird aktiviert, um das Auslesen von Konversationen zu verhindern.
Damit reagiert der Patch sowohl auf die ungewollte Netzwerkexponierung als auch auf die fehlenden Zugriffsbeschränkungen für besonders mächtige Tools.
Empfohlene Sofortmaßnahmen für betroffene Instanzen
Für Betreiber wird in der Beschreibung außerdem ein konkreter Notfallplan nahegelegt. Wer eine Ruflo-Instanz betreibt, die nach außen erreichbar ist, sollte schnell handeln:
- Firewall-Ports schließen: insbesondere Port 3001 sowie 27017.
- LLM-API-Keys rotieren, weil ein Abgriff als möglich gilt.
- Den AgentDB Pattern Store prüfen, ob injizierte Einträge gefunden werden (z. B. verdächtige agentdb_pattern-store-Einträge).
- Die MongoDB auf Anzeichen von Manipulation untersuchen.
- Container – sofern möglich – aus einer sauberen Basis neu aufsetzen, nicht nur „hinterherpatchen“.
Der Kernpunkt: Eine reine Softwareaktualisierung ist oft nicht ausreichend, weil Credentials und persistente Speicherinhalte bereits kompromittiert worden sein könnten.
Fazit: Patchen allein genügt nicht
Die Ruflo MCP-Schwachstelle zeigt eindrücklich, wie eng Container-Deployments, Tool-Bindings und KI-spezifische Persistenzmechanismen zusammenhängen. Der Fehler ermöglichte unauthentifizierte Remote Code Execution und führte anschließend zu potenziellem API-Key-Diebstahl, Datenabfluss und vor allem zu dauerhafter Manipulation der AI-Memory.
Wer Ruflo nutzt, sollte sofort auf Version 3.16.3 oder höher aktualisieren und parallel die empfohlenen Sicherheitsmaßnahmen umsetzen: Ports schließen, Schlüssel rotieren und die persistente KI-Lernbasis auditieren. Nur so lässt sich das Risiko eines langfristigen, schwer erkennbaren „KI-Verhaltensangriffs“ minimieren.
Quelle: https://thehackernews.com/2026/07/ruflo-mcp-flaw-lets-unauthenticated.html
