
Esecuzione di codice in remoto in DbGate tramite injection di functionName nell'endpoint loadReader — CVSS 8.8
functionNameGravità: Alta (CVSS 8.8)
CWE: CWE-94 — Controllo improprio della generazione di codice ('Code Injection')
Interessato: dbgate-api ≤ 7.1.8 (corretto in 7.1.9)
Avviso: GHSA-hv83-ggc4-v385
NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-48017
Riconoscimento: Romain Deperne
L'endpoint POST /runners/load-reader accetta un parametro functionName e lo interpola
direttamente in una stringa template JavaScript che viene poi eseguita in un processo forkato — senza alcuna
sanitizzazione o validazione. Qualsiasi utente autenticato (senza bisogno di permessi speciali) può uscire dalla
chiamata prevista ed eseguire JavaScript arbitrario, ottenendo l'esecuzione di codice remoto sul server.
Il runner forkato imposta require = null come sandbox, ma process.binding("spawn_sync") rimane raggiungibile:
process.binding("spawn_sync") è ancora raggiungibile e genera un vero processo del sistema operativo.
Stavo analizzando il sottosistema runner di DbGate per individuare la differenza tra i percorsi di esecuzione di codice
protetti e non protetti. Il runner start() in runners.js:292 è adeguatamente protetto — chiama
testStandardPermission('run-shell-script') e verifica platformInfo.allowShellScripting.
loadReader() fa la stessa cosa concettualmente (costruisce ed esegue uno script loader JS) ma non ha
nessuno di quei controlli. Ho tracciato il flusso dei dati:
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}` // ← no sanitization
functionName è controllato dall'attaccante e finisce all'interno di una template string eseguita. Il prefisso dbgateApi.
è l'unica cosa che lo precede, ed è aggirabile: chiudendo l'espressione con toString();,
iniettando il payload e commentando il (${props}) finale con // si ottiene JS valido.
File: packages/api/src/controllers/runners.js (loadReader → loaderScriptTemplate)
File: packages/tools/src/packageTools.ts:33 (compileShellApiFunctionName)
// packageTools.ts:33 — functionName flows in unsanitized
return `dbgateApi.${functionName}`;
// runners.js:64 — interpolated into the executed loader template
`const reader = await ${compileShellApiFunctionName(functionName)}(${JSON.stringify(props)});`
Script generato (iniettato):
const reader = await dbgateApi.toString();
process.binding("spawn_sync").spawn({ file:"/bin/sh", args:["/bin/sh","-c","id"], ... });
dbgateApi.toString//({});
compileShellApiFunctionName() era stato scritto per trasformare un nome breve in un percorso API completamente qualificato
(dbgateApi.<name>), fidandosi implicitamente che functionName fosse un identificatore. Il valore, tuttavia,
proviene direttamente dal corpo della richiesta HTTP. Poiché viene concatenato nel codice sorgente che successivamente
viene sottoposto a eval/fork, l'assunzione di fiducia si traduce in un RCE. La sandbox require = null non aiuta — il
metodo interno di Node process.binding("spawn_sync") la aggira.
Correzione (7.1.9): validare functionName rispetto a una rigorosa allow-list di identificatori prima di compilarlo
nello script del loader.
poc/rce_loadreader_functionname_injection.py — esercita l'endpoint reale end-to-end.
# with an existing JWT
python3 poc/rce_loadreader_functionname_injection.py http://localhost:3000 <JWT> 'id > /tmp/pwned'
# or log in first
python3 poc/rce_loadreader_functionname_injection.py http://localhost:3000 --login admin password 'id'
Lo script costruisce il payload functionName, lo invia a POST /runners/load-reader, e la
chiamata spawn_sync iniettata esegue il comando nel processo runner forkato.
RCE autenticata sull'host dell'API DbGate. DbGate è una GUI per la gestione di database spesso distribuita con ampia raggiungibilità di rete verso database interni — l'esecuzione di codice su di essa rappresenta un forte pivot verso il livello dati.
Divulgato in modo responsabile. PoC pubblicato dopo il rilascio della correzione, per i difensori e l'ingegneria del rilevamento.