WaratekVRT Sign in
Reset
More filters (2)
Columns
Protection: None✕Vendor com.arcadedb✕
Overview 5 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
5matches 0protected0.0% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 5 100.0%
Critical 3 60.0% High 2 40.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 5 100.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 5 100.0%
split by peak 2 / month
May 26Jun 26Jul 26Aug 26Sep 26
5 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2026-65831 High 2026-09-15 No exploit published No public exploit ArcadeDB is a Multi-Model DBMS. Prior to 26.7.1, a reader-role user can submit POST /api/v1/command/{database} with language: js because PolyglotQueryEngine.command, PolyglotQueryEngine.analyze, and PolyglotQueryEngine.registerFunctions do not enforce database-administrator authorization. GraalPolyglotEngine also permits scripts to bypass the allowedPackages whitelist by reflecting from the bound database object through database.getClass().getClassLoader().loadClass to arbitrary host classes. These cooperating defects allow a read-only database user to read arbitrary host files outside the database scope. Process creation is already blocked, so OS command execution is not confirmed. The issue is distinct from CVE-2026-44221, CVE-2026-54076, and CVE-2026-54077. This issue is fixed in version 26.7.1.
CVE-2026-54076 High 2026-09-15 No exploit published No public exploit ArcadeDB is a Multi-Model DBMS. Prior to 26.6.1, the fix for CVE-2026-44221 added an UPDATE_SCHEMA authorization check only to LocalDocumentType.createProperty, while the remaining public schema mutators in engine/src/main/java/com/arcadedb/schema/LocalDocumentType.java and engine/src/main/java/com/arcadedb/schema/LocalProperty.java remained unchecked. An authenticated identity, including a read-only API token without UPDATE_SCHEMA permission, can use DROP PROPERTY, ALTER TYPE, or ALTER PROPERTY through the database command/query HTTP endpoints to rename types, change inheritance, alter aliases or buckets, drop properties, and change property constraints. The issue does not directly disclose or write record data, but unauthorized schema mutation can corrupt the meaning of stored records and breach the documented permission model. This issue is fixed in version 26.6.1.
CVE-2026-67342 Critical 2026-08-01 No exploit published No public exploit ArcadeDB versions before 26.7.2 contain an authorization bypass vulnerability in HTTP handlers for time series, batch, Prometheus, and Grafana endpoints that fail to validate database access permissions. Attackers can access and modify databases they are not authorized to use by directly calling affected endpoints with arbitrary database parameters.
CVE-2026-67341 Critical 2026-08-01 No exploit published No public exploit ArcadeDB versions before 26.7.2 fail to enforce scripting authorization checks on the SQL DEFINE FUNCTION statement with LANGUAGE js. Attackers with database access can execute arbitrary JavaScript code by submitting DEFINE FUNCTION statements, bypassing security controls intended to restrict scripting to administrators.
CVE-2026-44221 Critical 2026-05-12 No exploit published No public exploit ArcadeDB is a Multi-Model DBMS. Starting in version 21.10.1 and prior to version 26.4.2, 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. This vulnerability is fixed in 26.4.2.