RufRoot (CVE-2026-59726): Unauthentifizierte Remote Code Execution über die MCP Bridge von Ruflo — CVSS 10.0

TL;DR — 90 Sekunden

Betroffen?

Ruflo-Deployments, bei denen die MCP Bridge (Standardport 3001) aus dem Netz erreichbar ist — laut Docker-Compose-Standardkonfiguration ist das jede unverändert betriebene Installation.

Risiko?

Unauthentifizierte Remote Code Execution (CVSS 10.0) über POST /mcp und das Tool ruflo__terminal_execute — kein Login, kein Token, keine Nutzerinteraktion nötig. Noma Security demonstrierte eine vollständige Kompromittierungskette bis zu API-Key-Diebstahl, Datenbankzugriff und persistenter Backdoor.

Sofortmaßnahme?

Port 3001 (und 27017 für die genutzte MongoDB) aus dem öffentlichen Netz nehmen, auf die gefixte Version (PR #2521 / GHSA-c4hm-4h84-2cf3) aktualisieren, MCP_AUTH_TOKEN setzen.

Empfehlung?

Sofort handeln, wenn eine Ruflo-Instanz erreichbar ist — diese Lücke ist trivial ausnutzbar (ein einzelner curl-Request) und liefert direkte Codeausführung.

Kritikalität?

kritisch (Hero-Badge) — CVSS 10.0, unauthentifiziert, trivialer Exploit; die Quellenlage stützt sich bislang auf eine einzelne Sicherheitsfirma (Noma Security), eine bestätigte aktive Ausnutzung in freier Wildbahn liegt uns nicht vor.

Was ist das Problem?

Ruflo ist eine quelloffene Plattform zur Orchestrierung von KI-Agenten: Entwickler bauen damit „agentische Schwärme“ aus bis zu 100 kollaborierenden Agenten, mit persistentem Gedächtnis über Sitzungen hinweg und Werkzeug-Ausführung über das Model Context Protocol (MCP). Die MCP Bridge ist der zentrale Express.js-Server, über den externe MCP-Clients (Agenten, Tools, IDEs) auf die 233 verfügbaren Ruflo-Werkzeuge zugreifen — darunter Shell-Zugriff, Datenbankoperationen, Agenten-Verwaltung und Speicheroperationen.

Der Endpoint POST /mcp implementiert das MCP-JSON-RPC-Protokoll und leitet Tool-Aufrufe direkt an executeTool() weiter — ohne jede Authentifizierungsschicht. Ein zwar vorhandenes Command-Blocklist (AUTOPILOT_BLOCKED_PATTERNS) schränkt gefährliche Operationen ein, greift aber ausschließlich innerhalb des Autopilot-Flows der Anwendung — der direkte /mcp-Endpoint umgeht diese Prüfung vollständig. Kombiniert mit dem Standard-Bind an 0.0.0.0 in der mitgelieferten docker-compose.yml (Port 3001 auf allen Netzwerk-Interfaces) ergibt sich unauthentifizierte Remote Code Execution mit einem einzelnen HTTP-Request:

curl -s -X POST <target>/mcp -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"ruflo__terminal_execute","arguments":{"command":"id && hostname"}}}'

Wer ist betroffen?

Besonders relevant für Unternehmen, die Ruflo experimentell oder produktiv für interne Automatisierung, Coding-Agenten oder Workflow-Orchestrierung einsetzen: Die Standardkonfiguration priorisiert Setup-Einfachheit über Sicherheit — ein Muster, das bei KI-Agent-Tooling in den letzten Monaten wiederholt zu kritischen Lücken geführt hat (vergleichbar mit den auf diesem Blog bereits dokumentierten Langflow- und LiteLLM-Fällen).

Auswirkungen

Noma Security demonstrierte eine vollständige, achtstufige Angriffskette: (1) Reconnaissance über tools/list, das alle 233 verfügbaren Werkzeuge auflistet; (2) Codeausführung über terminal_execute; (3) Diebstahl von API-Schlüsseln aus Umgebungsvariablen — OpenAI, Anthropic, Google, OpenRouter waren in der demonstrierten Umgebung erreichbar; (4) „Weaponisierung“ weiterer Agenten über ruflo__swarm_init und ruflo__agent_spawn, um vom Angreifer kontrollierte Schwärme zu erzeugen; (5) Speicher-Poisoning durch Einschleusen manipulierter Muster in die Lernpipeline via ruflo__agentdb_pattern-store; (6) Datendiebstahl durch unauthentifizierten Zugriff auf die zugrunde liegende MongoDB (Auslesen aller Konversationen); (7) Persistenz durch Einschleusen eines Beacon-Skripts unter /app/beacon.js mit Startup-Hook; (8) Verwischen der Spuren durch Löschen der Shell-Historie.

Der Effekt reicht damit deutlich über klassische Server-Kompromittierung hinaus: Neben vollständiger Codeausführung sind gestohlene LLM-API-Schlüssel, kompromittierte Agenten-Schwärme und manipulierte, dauerhaft in der Lernpipeline verankerte Verhaltensmuster mögliche Folgen — letzteres ist besonders schwer vollständig zu bereinigen, da betroffene Muster in nachgelagerten Agenten-Entscheidungen fortwirken können.

Mitigation / Sofortmaßnahmen

Operativer Entscheidungsblock

• Heute handeln, wenn … eine Ruflo-MCP-Bridge (Port 3001) aus dem Internet oder einem nicht vertrauenswürdigen internen Netz erreichbar ist.
• Mit Priorität prüfen, wenn … Ruflo intern eingesetzt wird und Sie nicht sicher wissen, ob MCP_AUTH_TOKEN gesetzt ist.
• Beobachten, wenn … Sie bereits auf den gepatchten Stand aktualisiert haben, MCP_AUTH_TOKEN gesetzt ist und die Bridge nicht öffentlich erreichbar ist.

Schritt 1 — Sofort: Netzwerkzugriff einschränken

# Firewall-Regeln fuer die MCP-Bridge und die zugehoerige MongoDB
sudo ufw deny 3001/tcp
sudo ufw deny 27017/tcp

# Falls Docker Compose genutzt wird: Port-Mapping auf localhost beschraenken
# statt "3001:3001" -> "127.0.0.1:3001:3001" in docker-compose.yml

Schritt 2 — Auf gepatchten Stand aktualisieren

# Ruflo auf den Stand nach PR #2521 / GHSA-c4hm-4h84-2cf3 aktualisieren
git pull
# oder: aktuelles Release-Image ziehen, das den Fix enthaelt

# Pflicht-Umgebungsvariable fuer Authentifizierung setzen
export MCP_AUTH_TOKEN="$(openssl rand -hex 32)"

# Terminal-Zugriff bleibt nach dem Patch standardmaessig deaktiviert;
# nur explizit aktivieren, wenn zwingend benoetigt:
# export MCP_ENABLE_TERMINAL=true

Schritt 3 — Nach dem Patch verifizieren

# Unauthentifizierten Zugriff testen -- sollte nach dem Patch fehlschlagen
curl -s -X POST <host>/mcp -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
# erwartete Antwort: Fehler/Ablehnung wegen fehlender Authentifizierung,
# nicht die Liste der 233 Tools

Detection / Prüfung

Bestand feststellen

# Pruefen, ob eine Ruflo-MCP-Bridge auf Port 3001 erreichbar ist
nmap -p 3001 <host-oder-range>

# Unauthentifizierten Zugriff testen (nur gegen eigene Systeme!)
curl -s -X POST <host>/mcp -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
# Erhalten Sie eine Liste von ~233 Tools zurueck, ist die Instanz verwundbar

Kompromittierung prüfen

# Auf verdaechtige Dateien pruefen, die als Backdoor dienen koennten
ls -la /app/beacon.js 2>/dev/null && echo "VERDAECHTIG: beacon.js gefunden"

# MongoDB auf unautorisierten Zugriff/Manipulation pruefen
# (Backend-DB von Ruflo, Standardport 27017 -- Zugriffslogs pruefen)

# Shell-Historie auf Luecken/Manipulation pruefen (Angreifer loeschen typischerweise Spuren)
history | tail -100
cat ~/.bash_history | wc -l

Laufzeit-Indikatoren

• Unerwartete ausgehende Verbindungen des Ruflo-Bridge-Prozesses (Exfiltration von API-Keys)
• Neue oder unerwartete Einträge in ruflo__agentdb_pattern-store (Speicher-Poisoning)
• Unbekannte Agenten-Schwärme, die über swarm_init/agent_spawn erzeugt wurden, ohne dass dies beabsichtigt war
• Ungewöhnlich hohe Nutzung von LLM-API-Kontingenten (OpenAI/Anthropic/Google/OpenRouter) außerhalb bekannter Workloads

Betreiberempfehlung

Mid-Market

Prüfen Sie umgehend, ob Ruflo irgendwo im Einsatz ist — auch als „Schatten-IT“-Experiment einzelner Teams, das außerhalb des offiziellen Software-Inventars läuft. Ist eine Instanz erreichbar, Port 3001/27017 sofort aus dem öffentlichen Netz nehmen und auf den gepatchten Stand aktualisieren. Rotieren Sie vorsorglich alle LLM-API-Schlüssel, die in der Ruflo-Umgebung konfiguriert waren, unabhängig davon, ob eine Kompromittierung bestätigt ist.

Enterprise

Dieser Fall unterstreicht ein wiederkehrendes Muster bei KI-Agent-Tooling: Frameworks, die auf schnelle Inbetriebnahme optimiert sind, binden Management- und Steuerungs-Schnittstellen häufig standardmäßig an alle Interfaces und verzichten auf Authentifizierung „der Einfachheit halber“. Etablieren Sie ein Inventar aller MCP-Server und Agent-Orchestrierungs-Tools im Unternehmen — offiziell eingeführt oder nicht — und prüfen Sie deren Standardkonfiguration explizit auf offene Management-Ports, bevor sie produktiv genutzt werden.

Entscheidungsblock

• Sofort handeln: Port 3001/27017 absichern, auf gepatchten Stand aktualisieren, MCP_AUTH_TOKEN setzen.
• Zusätzlich: LLM-API-Schlüssel rotieren, AgentDB und MongoDB auf Manipulation prüfen.
• Beobachten: Weitere Advisories zu ähnlichen MCP-Bridge-Mustern in anderen Agent-Orchestrierungs-Frameworks — das architektonische Problem (offene Management-API ohne Auth) ist nicht Ruflo-spezifisch.

Fazit

RufRoot ist ein weiteres Beispiel eines Musters, das sich bei KI-Agent-Tooling in den letzten Monaten wiederholt: Eine Steuerungsschnittstelle, die für maschinelle statt menschliche Clients gedacht ist, wird der Einfachheit halber ohne Authentifizierung ausgeliefert — unter der stillschweigenden Annahme, dass sie schon nicht öffentlich erreichbar sein wird. Diese Annahme hält in der Praxis selten: Standard-Docker-Compose-Konfigurationen binden Ports oft an alle Interfaces, und „nur intern“ wird schnell zu „aus dem Internet erreichbar“, sobald ein Cloud-Provider, ein NAT-Gateway oder ein falsch konfigurierter Load Balancer ins Spiel kommt. Die architektonische Lehre ist dieselbe wie bei den bereits auf diesem Blog dokumentierten Fällen zu Langflow und LiteLLM: Jede Management- oder Tool-Ausführungs-Schnittstelle eines KI-Agent-Frameworks ist ein produktiver, privilegierter Dienst und muss von Anfang an so behandelt werden — mit Authentifizierung per Default, nicht als nachträgliche Option.

Quellen

• Noma Security — RufRoot: The MCP Bridge Vulnerability That Turns Agents Into Rogue Admins (CVE-2026-59726)

Hinweis: Die technischen Details zu dieser Lücke stützen sich auf eine einzelne Sicherheitsfirma als Quelle. Wir haben keine unabhängige zweite Quelle (z. B. NVD-Eintrag oder Ruflo-eigene Advisory-Seite) gefunden, die die genannten Details zum Zeitpunkt der Recherche bestätigt. Prüfen Sie vor operativen Entscheidungen die Original-Advisory sowie das Github-Repository von Ruflo (GHSA-c4hm-4h84-2cf3, PR #2521) auf aktuelle Informationen.