Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
About 14 HTTP handlers resolve the {database} path param and call getDatabase(...) WITHOUT user.canAccessToDatabase(...) and without setting the engine principal, because they extend AbstractServerHttpHandler directly instead of DatabaseAbstractHandler (which holds the only per-database gate at DatabaseAbstractHandler.java:69,88-90). Affected: PostBatchHandler:129, PostTimeSeriesWriteHandler:115, PostPrometheusWriteHandler:83, PostTimeSeriesQueryHandler:69, GetTimeSeriesLatestHandler:58, PostGrafanaQueryHandler:69, GetGrafanaHealthHandler:49, GetGrafanaMetadataHandler:52, GetPromQLQueryHandler:63, GetPromQLQueryRangeHandler:71, GetPromQLLabelsHandler:56, GetPromQLLabelValuesHandler:62, GetPromQLSeriesHandler:72, PostPrometheusReadHandler:85. The engine fallback is also void: LocalDatabase.checkPermissionsOnDatabase:711 early-returns when getCurrentUser()==null. Exploit: a user authorized only for DB 'a' calls POST /api/v1/batch/b, POST /api/v1/ts/b/write, GET…
Recommended action: Upgrade to 26.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A user holding only reader (read-only) privileges on a single database could execute arbitrary JVM code by sending a "language": "js" command to the POST /api/v1/command/{database} HTTP endpoint, and use it to read arbitrary files on the host filesystem (e.g. /etc/passwd, configuration files), outside the scope of the database itself. Two cooperating defects made this possible: 1. Missing authorization on the scripting path (CWE-863 / CWE-269). Polyglot script execution (js and other GraalVM languages) never went through the database authorization checks applied to SQL/Cypher, so any authenticated principal - regardless of database role - could run scripts. 2. Sandbox whitelist bypass. The GraalVM sandbox restricts direct class lookups to a configured allowedPackages list, but a script could reach arbitrary classes by reflecting off the bound database object: database.getClass().getClassLoader().loadClass("java.io.File"). Process creation was already blocked…
Recommended action: Upgrade to 26.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Authenticated users and API tokens scoped to a specific database could read, write, and mutate schema on any other database on the same server. Two distinct defects contributed: (1) ServerSecurityUser.getDatabaseUser() returned a DB user with an uninitialized fileAccessMap, which requestAccessOnFile treated as allow-all; (2) ArcadeDBServer.createDatabase() omitted factory.setSecurity(...) so any database created via POST /api/v1/server {"command":"create database X"} had its entire record-level authorization system silently disabled. In combination, record-level and database-level authorization could be bypassed by any authenticated principal. Patches Upgrade to version 26.4.2 Resources https://github.com/ArcadeData/arcadedb/commit/04110c06315da55604ac107f71fe7182f3a3deb8
Recommended action: Upgrade to 26.4.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.