
Удаленное выполнение кода в DbGate через инъекцию functionName в конечной точке loadReader — CVSS 8.8
functionNameСерьезность: Высокая (CVSS 8.8)
CWE: CWE-94 — Неправильный контроль генерации кода ('Внедрение кода')
Затронуто: dbgate-api ≤ 7.1.8 (исправлено в 7.1.9)
Уведомление: GHSA-hv83-ggc4-v385
NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-48017
Автор: Romain Deperne
Точка входа POST /runners/load-reader принимает параметр functionName и вставляет его напрямую в JavaScript шаблонную строку, которая затем выполняется в форкнутом процессе — без какой-либо санитации или проверки. Любой аутентифицированный пользователь (без специальных разрешений) может выйти за пределы предполагаемого вызова и выполнить произвольный JavaScript, получив удаленное выполнение кода на сервере.
Форкнутый раннер устанавливает require = null в качестве песочницы, но это легко обходится: все еще доступен и запускает реальный системный процесс.
process.binding("spawn_sync")Я проводил аудит подсистемы раннеров DbGate на предмет разрыва между защищенными и незащищенными путями выполнения кода. Раннер start() в runners.js:292 правильно защищен — он вызывает testStandardPermission('run-shell-script') и проверяет platformInfo.allowShellScripting.
loadReader() делает концептуально похожую вещь (он создает и запускает JS-скрипт загрузчика), но не имеет ни одной из этих проверок. Я проследил поток данных:
runners.js:353 loadReader({ functionName, props })
runners.js:366 loaderScriptTemplate(prefix, functionName, ...)
runners.js:64 `... ${compileShellApiFunctionName(functionName)}(${JSON.stringify(props)});`
packageTools.ts:33 return `dbgateApi.${functionName}` // ← нет санитации
functionName контролируется атакующим и попадает внутрь выполняемой шаблонной строки. Префикс dbgateApi. — единственное, что стоит перед ним, и его можно обойти: закрыв выражение с помощью toString();, внедрив полезную нагрузку и закомментировав завершающую часть (${props}) с помощью //, получаем корректный JavaScript.
Файл: packages/api/src/controllers/runners.js (loadReader → loaderScriptTemplate)
Файл: packages/tools/src/packageTools.ts:33 (compileShellApiFunctionName)
// packageTools.ts:33 — functionName поступает без санитации
return `dbgateApi.${functionName}`;
// runners.js:64 — интерполируется в выполняемый шаблон загрузчика
`const reader = await ${compileShellApiFunctionName(functionName)}(${JSON.stringify(props)});`
Сгенерированный (внедренный) скрипт:
const reader = await dbgateApi.toString();
process.binding("spawn_sync").spawn({ file:"/bin/sh", args:["/bin/sh","-c","id"], ... });
dbgateApi.toString//({});
compileShellApiFunctionName() был написан для преобразования короткого имени в полный путь API (dbgateApi.<name>), неявно доверяя, что functionName является идентификатором. Однако значение поступает напрямую из тела HTTP-запроса. Поскольку оно конкатенируется в исходный код, который затем выполняется через eval/форкается, такое доверие приводит к RCE. Песочница require = null не помогает — внутренний process.binding("spawn_sync") в Node ее обходит.
Исправление (7.1.9): проверять functionName на соответствие строгому списку разрешенных идентификаторов перед компиляцией в скрипт загрузчика.
poc/rce_loadreader_functionname_injection.py — управляет реальной конечной точкой от начала до конца.
# с существующим JWT
python3 poc/rce_loadreader_functionname_injection.py http://localhost:3000 <JWT> 'id > /tmp/pwned'
# или сначала войти
python3 poc/rce_loadreader_functionname_injection.py http://localhost:3000 --login admin password 'id'
Скрипт формирует полезную нагрузку functionName, отправляет ее на POST /runners/load-reader, и внедренный вызов spawn_sync выполняет команду в форкнутом процессе раннера.
Аутентифицированное RCE на хосте API DbGate. DbGate — это графический интерфейс управления базами данных, часто развертываемый с широким сетевым доступом к внутренним базам данных — выполнение кода на нем является мощной точкой для перехода к уровню данных.
Раскрыто ответственно. PoC опубликован после выпуска исправления для защитников и инженеров по обнаружению.