CVE-2026-93598 in ArcadeDB
Summary
by MITRE • 09/18/2026
ArcadeDB (Maven artifact com.arcadedb:arcadedb-engine) through 26.8.1 contains an incomplete deny-list in the polyglot script sandbox: com.arcadedb.query.polyglot.HostClassLookupFilter.DENIED lists java.util.ResourceBundle as a bare class name, which is matched by exact equality and therefore does not cover its subclasses, while ScriptTriggerExecutor.ALLOWED_PACKAGES permits java.util.*. A user with the UPDATE_SCHEMA privilege (sufficient to create or alter a JavaScript trigger; no server-admin rights required) can reference java.util.PropertyResourceBundle or java.util.ListResourceBundle and invoke the inherited static ResourceBundle.getBundle(String) to read .properties resources from the application classpath, which the sandbox (IOAccess.NONE, with java.io.**, java.nio.** and java.net.** denied) is intended to make unreachable. This can disclose packaged application configuration such as database credentials and API keys; the advisory states the issue does not provide arbitrary host filesystem read or remote code execution. Fixed in 26.9.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in ArcadeDB versions through 26.8.1 represents a critical failure in the implementation of its polyglot script sandbox, specifically within the HostClassLookupFilter mechanism. This security flaw stems from an incomplete deny-list strategy that relies on exact string matching rather than hierarchical class resolution. The configuration explicitly lists java.util.ResourceBundle as a denied class name but fails to account for subclasses such as java.util.PropertyResourceBundle and java.util.ListResourceBundle. Because Java's type system allows these subclasses to inherit static methods, the sandbox inadvertently permits access to functionality that was intended to be restricted. This oversight is compounded by the ALLOWED_PACKAGES configuration which explicitly whitelists the entire java.util package namespace via a wildcard pattern, creating a conflict where the specific deny-list entry for ResourceBundle is bypassed due to the broader allowance of its parent or sibling classes depending on how the class loader resolves the reference during script execution.
From an operational perspective, this architectural flaw allows any user possessing UPDATE_SCHEMA privileges to execute arbitrary JavaScript triggers that can access restricted Java APIs without requiring server-administrator rights. The attacker leverages the inherited static method ResourceBundle.getBundle(String) to load property files from the application's classpath. Although the sandbox is configured with IOAccess.NONE and explicitly denies java.io, java.nio, and java.net packages to prevent file system and network operations, this specific vector bypasses those restrictions by accessing resources through the Java Resource Bundle mechanism rather than direct I/O streams. This capability effectively neutralizes a key security control designed to isolate untrusted script execution from sensitive application data.
The impact of this vulnerability is significant as it leads to unauthorized disclosure of confidential configuration data stored within .properties files on the classpath. Attackers can extract sensitive information such as database connection strings, credentials for external services, and API keys that are packaged with the ArcadeDB server or its plugins. While the advisory clarifies that this issue does not result in arbitrary host file system reads or remote code execution in the traditional sense of executing native binaries, it constitutes a severe confidentiality breach. The ability to read configuration files allows an attacker to map out the infrastructure and potentially use stolen credentials for lateral movement within the network environment where ArcadeDB is deployed.
This vulnerability aligns with CWE-284 Improper Access Control, as the application fails to properly restrict access to sensitive resources based on user privileges or sandbox boundaries. It also maps to MITRE ATT&CK technique T1530 Data from Cloud Storage Object or Local System, specifically involving data exfiltration through unauthorized file system reads via API abuse. The root cause is a classic example of insecure default configurations and insufficient validation of class hierarchies in security filters. To mitigate this risk, organizations must upgrade to ArcadeDB version 26.9.1 where the deny-list logic has been corrected to properly handle subclass inheritance or restrict access at the package level more rigorously. Until an upgrade is performed, administrators should enforce strict least-privilege policies by revoking UPDATE_SCHEMA privileges from untrusted users and ensuring that sensitive configuration files are not stored in locations accessible via standard Java resource loading mechanisms within the server environment.