RufRoot: Eine nicht authentifizierte Anfrage an Ruflos MCP-Brücke führte Befehle aus, stahl Schlüssel und vergiftete den KI-Speicher

Am 30. Juni 2026, Noma Labs übergab dem Maintainer von Ruflo einen funktionierenden Exploit gegen das Projekt selbst. Der Forschungsbereich von Noma Security hatte herausgefunden, dass Ruflo – eine Open-Source-Plattform für Agentenorchestrierung, die früher als Claude Flow veröffentlicht wurde – eine standardmäßige Docker-Compose-Bereitstellung auslieferte, die ihre Model Context Protocol-Brücke an Port 3001 auf allen Netzwerkschnittstellen band und überhaupt keine Authentifizierung verlangte. Eine einzige HTTP-Anfrage an den /mcp-Endpunkt genügte, um im Container als der node-Benutzer Shell-Befehle auszuführen, und von dieser Shell aus konnte ein Angreifer jeden API-Schlüssel eines LLM-Anbieters in der Umgebung lesen, jede gespeicherte Konversation ausleiten, Agentenschwärme starten, die über die Schlüssel des Opfers abgerechnet würden, und Anweisungen in den AgentDB-Lernspeicher schreiben, der die Antworten der KI für jeden Nutzer dieser Instanz weiter lenken würde. Die Schwachstelle ist CVE-2026-59726, auch bekannt als RufRoot, mit CVSS 10.0 bewertet und innerhalb von 24 Stunden in 3.16.3 behoben. Keine von uns gelesene Quelle berichtet, dass sie in freier Wildbahn ausgenutzt wurde. Der eigene Eintrag des Archivs zu dieser Schwachstelle mit seiner Quellenliste und Vertrauensstufe steht in dem KI-Vorfallarchiv, neben den anderen MCP- und Infrastruktureinträgen, die rund um ihn abgelegt wurden.

Die Voreinstellung, die die Tür öffnete

Ruflo ist das, was Noma Labs ein Agent-Meta-Harness nennt: eine selbst gehostete Ebene für Schwärme von bis zu 100 Agenten, entwickelt für Claude Code und OpenAI Codex, mit Langzeitgedächtnis und einem integrierten MCP-Server für Tool-Aufrufe. Das übliche Setup ist das, was Noma beschreibt – das Repository klonen, LLM-API-Schlüssel hinzufügen und docker compose up -d starten. Die Standard-Compose-Datei des Projekts band die Bridge an 0.0.0.0 auf Port 3001 und band die zugehörige MongoDB an alle Schnittstellen auf 27017, wobei die Mongo-Authentifizierung deaktiviert war. Wie weit das reicht, hängt von der Firewall, der Sicherheitsgruppe und der Netzwerksegmentierung rund um die Bereitstellung ab; Nomas eigene Formulierung lautet, dass jede über das Netzwerk erreichbare Instanz ohne Authentifizierung vollständig ausnutzbar war.

Die MCP Bridge ist ein Express.js-Server, der über HTTP eingehende JSON-RPC-Anfragen in Aufrufe an Ruflos interne Tool-Bibliothek umwandelt. In der verwundbaren Codezeile enthielt diese Bibliothek 233 Tools, die Shell-Zugriff, Datenbankoperationen, Agentenverwaltung und die Speicherung von Erinnerungen abdeckten. Nomas Bericht ist unverblümt darüber, was das daraus macht: „Die MCP Bridge ist keine zufällige zusätzliche Debug-Schnittstelle; vielmehr ist sie Ruflos zentrales Nervensystem. Jeder Tool-Aufruf, jede Agentenaktion, jede Speicheroperation läuft über die MCP Bridge.“

Die Authentifizierungsschicht fehlte, sie war nicht bloß schwach. POST /mcp und POST /mcp/:group implementieren das MCP-JSON-RPC-Protokoll und leiten eingehende tools/call-Anfragen direkt an die interne executeTool()-Funktion weiter. Ruflo unterhielt zwar eine Befehls-Blockliste, AUTOPILOT_BLOCKED_PATTERNS, die gefährliche Shell-Operationen stoppen sollte, doch die GitHub-Advisory stellt ausdrücklich klar, dass sie „nur im Autopilot-Ablauf durchgesetzt wurde. POST /mcp und POST /mcp/:group umgingen sie.“ Ein nicht authentifizierter Aufruf mit der Bezeichnung ruflo__terminal_execute führte daher beliebige Befehle als node-Benutzer des Containers aus, in der Advisory als uid 1000 verzeichnet, ohne dass ein Token, eine Sitzung oder eine vorherige Interaktion erforderlich war. Für das, was als Nächstes kam, war keine Privilegienerhöhung nötig: Die Anmeldedaten, die Agenten-APIs, der Memory-Speicher und die Datenbank waren alle von dieser Shell aus erreichbar.

Die Kette in acht Schritten

Noma Labs veröffentlichte einen achtstufigen Proof of Concept und bestätigte jeden Schritt live gegen eine Standardbereitstellung von Ruflo auf AWS EC2, wobei Out-of-Band-Callbacks an Burp Collaborator genutzt wurden, um Ausführung und Exfiltration zu verifizieren. Die Schritte sind keine spekulativen Konsequenzen, die auf einen theoretischen Fehler aufgesattelt wurden; sie sind eine nachgewiesene Abfolge, und der Abschnitt zu den Gegenmaßnahmen im Sicherheitshinweis ist für Betreiber geschrieben, die sich möglicherweise bereits darin befinden.

Die Reconnaissance steht an erster Stelle, weil die Werkzeugliste für jeden Aufrufer öffentlich ist: tools/list liefert alle 233 Einträge ohne Anmeldedaten. Die Befehlsausführung folgt aus demselben Endpunkt, und Nomas Proof of Concept bestätigte dies mit einem Out-of-Band-Callback statt eines Rückschlusses aus einem Antwort-Body. Der Umgebungsschritt ist derjenige, der aus einer Host-Kompromittierung ein Abrechnungs- und Datenverlustproblem macht: Die Compose-Datei übergab Provider-Schlüssel an den Container, und Backend-Prozesse erbten die vollständige Umgebung über { ...process.env }, sodass ein einzelnes printenv sie ausgab. Diese Schlüssel ermöglichten dann ruflo__swarm_init und ruflo__agent_spawn, angreiferkontrollierte Swarms zu starten, die das Kontingent und die Rechenleistung des Opfers verbrauchten.

Schritt fünf ist derjenige, der die Intrusion überdauert. Mit ruflo__agentdb_pattern-store pflanzte Noma eine erfundene SOC2-Compliance-Richtlinie ein, die die KI anwies, in jedes anschließend generierte Deployment-Skript eine von Angreifern kontrollierte URL einzubetten. Da AgentDB genau dazu existiert, diese Art von Muster zu persistieren, damit sich das Verhalten der Agenten über Sitzungen hinweg verbessert, verhielt sich der injizierte Eintrag so, wie das System konzipiert war. „Zukünftige Unterhaltungen erzeugen von Angreifern beeinflusste Ausgaben, und der Benutzer kann es nicht erkennen“, heißt es in Nomas Bericht. Dark Reading, das die Schwachstelle am 29. Juli meldete, legte den Unterschied einem externen Experten dar: John Gallagher, Vizepräsident bei Viakoo, nannte es eine andere Problemklasse: „Das ist kein Ausnutzen von Softwarefehlern, es ist Speichervergiftung.“

Die verbleibenden Schritte sind konventionelle Post-Exploitation und wurden mit ungewöhnlicher Leichtigkeit ausgeführt. MongoDB im internen Docker-Netzwerk hatte keine Authentifizierung, daher installierten die Angreifer einen Client in /tmp, zogen Unterhaltungen ab und schafften sie nach außen. Persistenz entstand durch das Schreiben von /app/beacon.js, das Hinzufügen einer require('./beacon.js')-Zeile zu index.js und das Beenden von PID 1, woraufhin Dockers Neustartrichtlinie den Container mit aktivem Beacon zurückbrachte. Der letzte Schritt war das Leeren der Shell-Historie. Alles davon folgte aus einer einzigen nicht authentifizierten Anfrage; nichts in der Standardbereitstellung stoppte die Kette an irgendeinem Punkt.

Die Reparatur – und der Teil, den ein Patch nicht erreicht

Der Maintainer hat Ruflo 3.16.3innerhalb von 24 Stunden nach der Offenlegung am 30. Juni ausgeliefert, und GitHub hat den Sicherheitshinweis GHSA-c4hm-4h84-2cf3am 1. Juli 2026veröffentlicht. Die Behebung, die im Repository als ADR-166 geführt und in Pull Request 2521 zusammengeführt wurde, ändert die Standardeinstellungen, statt nur eine Prüfung hinzuzufügen:

• Die MCP-Bridge bindet an 127.0.0.1 standardmäßig; eine öffentliche Bindung erfordert MCP_AUTH_TOKEN, und der Prozess beendet sich beim Start mit einer fatalen Meldung, wenn das Token fehlt.

• Eine Bearer-Token-Middleware mit Vergleich in konstanter Zeit ist der Bridge vorgeschaltet.

• terminal_execute ist serverseitig hinter MCP_ENABLE_TERMINAL=true gesperrt, standardmäßig deaktiviert, und die Sperre wird auf /mcp, /mcp/:group sowie im Autopilot-Ablauf identisch durchgesetzt – das fehlende Glied, das es der offengelegten Kette ermöglicht hatte, eine Shell zu erreichen.

• MongoDB erfordert Authentifizierung, wobei ein Root-Passwort erforderlich ist, damit der Container startet.

• Der Bridge-Container verwendet ein schreibgeschütztes Root-Dateisystem mit tmpfs, eine CORS-Allowlist ersetzt den Wildcard, und CI-Regressionssperren decken die statische Konfiguration und das Laufzeitverhalten ab.

Nichts davon entfernt einen Eintrag, der bereits in AgentDB geschrieben wurde. Die Sicherheitswarnung rät Betreibern jeder exponierten Instanz, die Ports 3001 und 27017 sofort per Firewall zu blocken, die Anbieter-Schlüssel zu rotieren, den Pattern-Store auf injizierte agentdb_pattern-store-Einträge zu prüfen und sie zu entfernen, MongoDB auf Manipulationen zu prüfen und Container aus sauberen Images neu zu erstellen. Ihre Warnung ist ungewöhnlich direkt: „Eine gepatchte Neubereitstellung allein macht eine Vergiftung NICHT rückgängig.“ Nomas Bericht kommt zum selben Schluss – die Prüfung des Pattern-Stores ist Teil der Behebung, der Patch nicht.

Der Grund ist struktureller Art und nicht Fahrlässigkeit. Ein Musterspeicher, der künftige Modellausgaben prägt, kann nicht zwischen einer legitimen erlernten Anweisung und einer vom Angreifer eingepflanzten unterscheiden; beide treffen als Muster ein, und das System ist darauf ausgelegt, ihnen zu vertrauen. Das verwandelt eine Netzwerkschwachstelle in ein Problem der Datenintegrität mit einem unbekannten Rückstand, und es bedeutet, dass für einen Betreiber nicht nur die Frage zählt, ob der Port erreichbar war, sondern was der Speicher jetzt enthält.

Was gilt als gesichert und was nicht

Die technische Dokumentation hier ist primär und konsistent. Die Advisory benennt das betroffene Paket (npm ruflo unter 3.16.3), die gepatchte Version, die genauen Endpunkte, den Container-Benutzer und die beiden Ports; die Release-Hinweise des Maintainers beschreiben dieselbe Kette; Nomas Write-up liefert die Details des Proof of Concept; und unabhängige Medien – The Hacker News und Dark Reading am 29. Juli 2026, SecurityWeek am 30. Juli – berichten über denselben Mechanismus, ohne widersprüchliche Einzelheiten hinzuzufügen. Eine Forschungsnotiz der Cloud Security Alliance vom 5. August 2026 wiederholt die Abfolge und ordnet sie neben früheren nicht authentifizierten MCP- und Agent-Orchestrierungs-Schwachstellen ein, die sie verfolgt hatte. Das Archiv bewertet die Vertrauensstufe des Eintrags mit A, unbestritten, und kennzeichnet ihn als Meilenstein; seine Schweregradbewertung für den Eintrag ist hoch, getrennt vom CVSS-Score selbst.

Ein Detail zur Bewertung ist es wert, präzise benannt zu werden, denn zwei Primärdokumente widersprechen sich. GHSA-c4hm-4h84-2cf3 trägt CVSS 10.0 auf dem Vektor AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — die Scope-Änderung ist es, die ihn auf das Maximum treibt. Die Kopie desselben Advisories auf der Release-Seite von 3.16.3 beschreibt die Bewertung als „CVSS 9.8 critical". Der Datensatz der National Vulnerability Database, geprüft am 30. Oktober 2026, veröffentlicht am 9. Juli 2026 und mit Deferred markiert, führt die GitHub-10.0 als sekundäre Metrik und keine von NVD selbst verfasste Bewertung. Wir haben keine Erklärung für die 9.8-Zeile gefunden, und dieser Beitrag löst das nicht auf.

Die Zahlen zur Adoption sind geringer. Noma Labs beschrieb das Projekt damals mit mehr als 67.000 GitHub-Sternen, rund 10 Millionen Downloads und etwa 1 Million aktiven Nutzern; The Hacker News zitierte – wie die Cloud Security Alliance es zusammenfasste – mehr als 66.500 Sterne. Die Download- und Nutzerzahlen stammen von Noma selbst und sind nicht unabhängig verifiziert. Die Sternanzahl des Repositorys betrug am 30. Oktober 2026 80.198 – eine Prüfung der Reichweite des Projekts, kein Maß für Exposition, und keine Quelle hat veröffentlicht, wie viele Deployments tatsächlich aus einem Netzwerk heraus erreichbar waren.

Was nicht belegt ist, ist der am leichtesten aufblähbare Teil. Weder Noma noch der Maintainer noch irgendeine Publikation, die wir gelesen haben, behauptet, die Schwachstelle sei in freier Wildbahn ausgenutzt worden, und das Archiv verzeichnet für diesen Eintrag keinen tatsächlichen Schaden. Nomas Proof of Concept wurde gegen eine von den Forschenden kontrollierte Deployment-Umgebung auf EC2 ausgeführt; das zeigt, was eine Standardinstallation erlaubt, nicht, was eine bestimmte Produktionsinstanz erlitten hat. Es wurde keine Zahl internetexponierter Ruflo-Deployments veröffentlicht, und kein Betreiber hat die Ergebnisse eines AgentDB-Audits veröffentlicht, sodass sowohl die betroffene Population als auch die Menge des vorhandenen vergifteten Speichers unbekannt sind. Die Empfehlung der Cloud Security Alliance, exponierte Deployments als vollständig kompromittiert zu betrachten, ist eine durch Zero-Interaction-Exploitation gerechtfertigte Risikohaltung; sie ist kein Beweis dafür, dass ein Sicherheitsvorfall stattgefunden hat.

Warum das Archiv es als Wahrzeichen ausweist

Die wegweisende Markierung des Archivs beruht auf etwas Spezifischerem als einer Höchstpunktzahl. Ein CVSS 10.0-Fehler für Remote-Codeausführung in einem beliebten selbst gehosteten Dienst ist ein vertrautes Genre, und der Fix hier kam innerhalb von 24 Stunden. Was RufRoot unterscheidet, ist, dass der Exploit in der eigenen Lernpipeline der KI endete, wo die konventionelle Abhilfe — Upgrade, Neu-Deployment, Port schließen — die injizierte Anweisung an Ort und Stelle belässt und sie weiterhin Antworten prägt. Die Notiz der Cloud Security Alliance deutet es als Fallstudie für ein Muster, das sie bereits über Agent-Tooling hinweg dokumentiert hatte, einschließlich einer LangGraph-Checkpoint-Kette und einer nicht authentifizierten AutoGen Studio-Oberfläche, und argumentiert, dass persistenter Speicher, der zur Prägung des Verhaltens von Agenten genutzt wird, als sensibler Datenspeicher unter Integritätsüberwachung behandelt werden sollte statt als Cache.

Diese neue Einordnung ist die praktische Erkenntnis. Das sichtbare Artefakt dieses Vorfalls ist eine gepatchte Abhängigkeit und ein veröffentlichter Sicherheitshinweis; das unsichtbare ist jedes Muster, das eine AgentDB eines Betreibers noch enthalten mag, und es gibt weder ein veröffentlichtes Tool noch eine Signatur, die eine legitim erlernte Policy von einer eingeschleusten unterscheidet. Für die Organisationen, die die standardmäßige Compose-Datei hinter einem erreichbaren Netzwerk betrieben haben, ist die sinnvolle Reaktion diejenige, die sowohl Noma als auch der Sicherheitshinweis nennen: davon auszugehen, dass die Schlüssel gelesen wurden, sie zu rotieren und den Speicher zu prüfen, bevor man den Antworten vertraut, die er liefert.