Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
CVE-2026-48017 — Esecuzione di codice in remoto in DbGate tramite injection di functionName nell'endpoint loadReader — CVSS 8.8 | Kitploit
Strumenti/GitHubGitHub/romain-deperne/cve-2026-48017
Analisi delle VulnerabilitàAnalisi del CodiceExploitSfruttamento di Applicazioni WebPenetration TestingApprendimento e FormazioneSviluppo Payload
GitHubromain-deperne/cve-2026-48017

CVE-2026-48017

Esecuzione di codice in remoto in DbGate tramite injection di functionName nell'endpoint loadReader — CVSS 8.8

Vedi Repository
241 mese faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

CVE-2026-48017 — Esecuzione di codice remoto in DbGate tramite iniezione di functionName

Gravità: 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

TL;DR

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.

Analisi

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.

Componente interessato

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//({});

Causa principale

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.

Proof of Concept

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.

Cronologia della divulgazione

  • Segnalato privatamente al maintainer tramite GitHub Security Advisory
  • Corretto in DbGate 7.1.9
  • Advisory GHSA-hv83-ggc4-v385 pubblicato il 2026-05-22; assegnato CVE-2026-48017

Impatto

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.

Scarica lo strumento