RufRoot in Ruflo: Wenn eine offene MCP-Bridge zum Generalschlüssel für KI-Agenten wird

Unternehmen setzen Agentenplattformen ein, damit KI-Systeme nicht nur antworten, sondern Aufgaben ausführen: Dateien lesen, Datenbanken abfragen, Code starten, weitere Agenten koordinieren und Ergebnisse dauerhaft speichern. Genau diese Fähigkeiten machen eine aktuell offengelegte Schwachstelle in Ruflo so relevant. Bei anfälligen Standardinstallationen war die zentrale Model-Context-Protocol-Bridge ohne Authentifizierung über das Netzwerk erreichbar. Ein Angreifer konnte dadurch nicht nur Befehle im Container ausführen, sondern auch Modellzugangsdaten auslesen und den persistenten Speicher der Agenten manipulieren.

Die als „RufRoot“ bezeichnete Schwachstelle CVE-2026-59726 wurde am 29. Juli von Noma Labs technisch beschrieben. Sie betrifft Ruflo – früher Claude Flow –, eine Open-Source-Orchestrierungsplattform für Claude Code, Codex und Multi-Agenten-Workflows. Die Sicherheitslücke ist seit Version 3.16.3 behoben. Für Betreiber reicht ein Update allein jedoch nicht zwingend aus: War eine Instanz erreichbar, müssen auch Credentials, gespeicherter Agentenzustand und Datenbanken als mögliche Bestandteile des Vorfalls untersucht werden.

Das Praxisproblem: Ein Tool-Router ohne Zugangskontrolle

Ruflo bündelt Agentenaktionen in einer MCP-Bridge. Laut Noma Labs stellte diese Bridge 233 Werkzeuge bereit – darunter Shell-Ausführung, Datenbankoperationen, Agentenverwaltung und Schreibzugriffe auf den Langzeitspeicher. Damit ist sie kein harmloser Hilfsdienst, sondern eine privilegierte Laufzeitschnittstelle.

In der betroffenen docker-compose.yml wurde Port 3001 standardmäßig an 0.0.0.0 gebunden. Der Dienst konnte also auf allen Netzwerkschnittstellen lauschen. Ob er tatsächlich aus dem Internet erreichbar war, hing weiterhin von Firewalls, Security Groups, Reverse Proxies und Segmentierung ab. Netzwerk-erreichbare Instanzen verlangten an den relevanten MCP-Endpunkten jedoch keine Authentifizierung.

Über einen normalen MCP-Tool-Aufruf ließ sich das Werkzeug terminal_execute ansprechen. Eine vorhandene Sperrliste schützte nur den Autopilot-Ablauf; die Endpunkte /mcp und /mcp/:group umgingen diese Kontrolle. Das Ergebnis war unauthentifizierte Befehlsausführung als node-Benutzer mit UID 1000 im Bridge-Container. Für eine vollständige Kompromittierung der Agentenumgebung war keine Root-Eskalation nötig, weil bereits dieser Prozess Zugriff auf zentrale Laufzeitressourcen hatte.

Warum der Container allein keine ausreichende Grenze war

Die GitHub Security Advisory beschreibt die Wirkungskette präzise: Der Bridge-Prozess konnte Provider-API-Keys aus seiner Umgebung lesen, mit diesen Schlüsseln fremdgesteuerte Agentenschwärme starten und manipulierte Muster in den AgentDB-Lernspeicher schreiben. Zusätzlich lief MongoDB in der damaligen Standardkonfiguration ohne Authentifizierung im internen Docker-Netz.

Damit trafen mehrere Fehler aufeinander:

1. Netzwerkexposition: Bridge und MongoDB waren zu breit gebunden.
2. Fehlende Identitätsprüfung: Die MCP-Endpunkte akzeptierten Tool-Aufrufe ohne Token.
3. Zu große Werkzeugmenge: Ein Netzwerkaufruf konnte bis zur Shell-Ausführung durchgereicht werden.
4. Credential-Vererbung: Der Prozess besaß die Modellanbieter-Schlüssel, die er für seine legitime Arbeit benötigte.
5. Persistenter Agentenzustand: Schreibzugriff auf den Lernspeicher machte aus einem Laufzeitvorfall ein langfristiges Integritätsproblem.

Noma Labs demonstrierte die Kette in einer kontrollierten Standardinstallation auf AWS EC2. Nach Angaben der Forscher ließen sich Befehlsausführung und Datenabfluss über externe Rückrufe bestätigen. Das ist ein belastbarer Machbarkeitsnachweis, aber kein Beleg für massenhafte Ausnutzung. Die NVD-Bewertung führt CVE-2026-59726 mit CVSS 10,0 und dem Angriffsvektor Netzwerk; zum Zeitpunkt ihres Eintrags war dort keine bekannte Ausnutzung vermerkt.

Die gefährlichste Folge ist möglicherweise unsichtbar

Gestohlene API-Schlüssel und eine Shell sind klassische Incident-Response-Probleme. Das Memory Poisoning erweitert den Vorfall jedoch um eine agentenspezifische Dimension. Ein Angreifer konnte laut Advisory manipulierte agentdb_pattern-store-Einträge hinterlegen, die spätere Ausgaben beeinflussen. Solche Änderungen können einen Patch, Container-Neustart oder Austausch des Images überleben, wenn der persistente Datenspeicher erhalten bleibt.

Damit ähnelt der Agentenspeicher eher einer Konfigurations- oder Supply-Chain-Komponente als einem Chatverlauf. Sicherheitsrelevante Entscheidungen dürfen nicht davon ausgehen, dass persistente Erinnerungen vertrauenswürdig sind, nur weil sie aus dem eigenen System stammen. Entscheidend sind Herkunft, Schreibberechtigung, Änderungsverlauf und die Möglichkeit, auf einen bekannten sauberen Zustand zurückzugehen.

Was Version 3.16.3 verändert

Der Ruflo-Maintainer veröffentlichte Version 3.16.3 bereits am 1. Juli nach koordinierter Meldung. Die öffentliche Detailanalyse von Noma Labs folgte am 29. Juli. Die Korrekturen adressieren nicht nur einen einzelnen Endpunkt, sondern mehrere Grenzen:

• Die MCP-Bridge bindet standardmäßig nur noch an 127.0.0.1.
• Eine öffentliche Bindung schlägt ohne MCP_AUTH_TOKEN geschlossen fehl.
• Bearer-Token werden serverseitig geprüft.
• terminal_execute ist standardmäßig deaktiviert und erfordert MCP_ENABLE_TERMINAL=true.
• MongoDB-Authentifizierung ist aktiv; zum Start wird ein Root-Passwort verlangt.
• Das Root-Dateisystem der Bridge wird schreibgeschützt eingebunden.
• Eine CORS-Allowlist und Regressionstests ergänzen die Absicherung.

Das ist ein gutes Beispiel für „secure by default“: Nicht Administratoren müssen jede gefährliche Option einzeln finden und deaktivieren. Stattdessen erfordern öffentliche Erreichbarkeit und Shell-Werkzeuge eine bewusste Freigabe.

Konkrete Implikationen für Unternehmen

Betreiber sollten zuerst Ruflo- und frühere Claude-Flow-Installationen inventarisieren, einschließlich Entwicklungsrechnern, Test-VMs und inoffizieller Shadow-AI-Umgebungen. Entscheidend ist nicht nur, ob Port 3001 öffentlich sichtbar war. Auch Erreichbarkeit aus gemeinsam genutzten Kubernetes-Clustern, Entwickler-VPNs oder kompromittierbaren internen Netzen vergrößert das Risiko.

Für anfällige oder früher exponierte Instanzen sind fünf Schritte sinnvoll:

• auf mindestens 3.16.3 aktualisieren und Ports 3001 sowie 27017 auf notwendige Quellen begrenzen;
• alle im Container verfügbaren OpenAI-, Anthropic-, Google- und OpenRouter-Schlüssel rotieren;
• AgentDB gezielt auf unbekannte oder veränderte Pattern-Store-Einträge prüfen und einen sauberen Stand wiederherstellen;
• MongoDB, Container-Logs, Prozessstarts und ausgehende Verbindungen auf Manipulation untersuchen;
• Container aus vertrauenswürdigem Image neu aufbauen, statt nur den laufenden Prozess neu zu starten.

Architektonisch sollten MCP-Dienste wie privilegierte APIs behandelt werden: starke Authentifizierung, minimale Tool-Allowlist, getrennte Identitäten pro Agent, kurze Credential-Laufzeiten, Egress-Kontrollen und nachvollziehbare Audit-Logs. Shell-Ausführung gehört in eine isolierte Sandbox und sollte niemals automatisch aus einem allgemein erreichbaren Tool-Router verfügbar sein. Speicherzugriffe brauchen zusätzliche Regeln: sensible Einträge sollten signiert oder versioniert, Änderungen diffbar und Rollbacks getestet sein.

Risiken und Limitierungen der Bewertung

Die veröffentlichte Angriffskette bezieht sich auf die damalige Standard-Docker-Compose-Bereitstellung. Individuelle Installationen konnten durch lokale Firewalls oder Segmentierung geschützt sein; umgekehrt können eigene Reverse-Proxy-Regeln zusätzliche Exposition geschaffen haben. Die Forschung zeigt eine praktisch bestätigte Schwachstelle, aber keine bekannte breite Angriffskampagne. Auch die Zahl der GitHub-Sterne – rund 66.500 bei der Veröffentlichung – sagt nichts darüber aus, wie viele verwundbare Instanzen tatsächlich erreichbar waren.

Ebenso wäre es falsch, aus RufRoot abzuleiten, MCP sei grundsätzlich unsicher. Das Protokoll transportiert Tool-Aufrufe; die konkrete Sicherheitsgrenze entsteht durch Implementierung, Authentifizierung, Netzwerkdesign und die Rechte der bereitgestellten Werkzeuge. Gerade weil MCP leistungsfähig ist, müssen Betreiber diese Grenze explizit bauen.

Fazit

RufRoot ist mehr als eine weitere Container-RCE. Der Fall zeigt, wie sich klassische Fehlkonfigurationen mit den besonderen Eigenschaften agentischer Systeme verbinden: Eine offene Laufzeitschnittstelle führt zur Shell, die Shell zu Provider-Credentials und der Schreibzugriff auf persistenten Speicher zu langfristig manipuliertem Agentenverhalten.

Für Unternehmen lautet die wichtigste Konsequenz: Nach einer Agentenkompromittierung nicht nur patchen, sondern auch Identitäten, gespeicherten Zustand und nachgelagerte Aktionen untersuchen. Ein KI-Agent ist kein isoliertes Modell. Er ist eine privilegierte Anwendung aus Netzwerkdiensten, Tools, Credentials, Datenbanken und Erinnerung – und jede dieser Komponenten gehört in das Sicherheitsmodell.

Quellen: Noma Labs, „RufRoot: The MCP Bridge Vulnerability That Turns Agents Into Rogue Admins“, 29. Juli 2026, https://noma.security/blog/rufroot-the-mcp-bridge-vulnerability-that-turns-agents-into-rogue-admins-cve-2026-59726/; GitHub Security Advisory GHSA-c4hm-4h84-2cf3, https://github.com/ruvnet/ruflo/security/advisories/GHSA-c4hm-4h84-2cf3; Ruflo Release 3.16.3, https://github.com/ruvnet/ruflo/releases/tag/v3.16.3; NVD, CVE-2026-59726, https://nvd.nist.gov/vuln/detail/CVE-2026-59726; The Hacker News, „Ruflo MCP Flaw Lets Unauthenticated Attackers Run Commands and Poison AI Memory“, 29. Juli 2026, https://thehackernews.com/2026/07/ruflo-mcp-flaw-lets-unauthenticated.html.