Threat Intelligence Database

ArcadeDB versions before 26.9.1 fail to validate IPv6 transition addresses in the SSRF guard used by IMPORT DATABASE and server commands. Authenticated attackers can supply URLs resolving to NAT64, 6to4, or Teredo addresses embedding RFC 1918 or loopback IPv4 payloads to reach internal services and cloud metadata endpoints.

ArcadeDB before 26.9.1 contains an access control bypass vulnerability in the query_database tool exposed through the AI chat endpoints. The tool executes queries without binding the authenticated principal to DatabaseContext, causing per-type and per-bucket ACL checks to silently no-op and allowing authenticated users to read data they are explicitly denied at the per-type level. Attackers can prompt the AI assistant to execute queries against restricted types or buckets to retrieve sensitive data that would be rejected through normal query endpoints.

ArcadeDB (Maven artifact com.arcadedb:arcadedb-engine) through 26.8.1 enforces its per-type/per-record access-control rules only in LocalBucket, keyed on file id. Query-execution paths that reach record data through LSM index files or the TimeSeries engine never invoke that permission check, so an authenticated user who is denied readRecord/deleteRecord on a type can still, with a single ordinary SQL statement, read the type's indexed key values and record IDs (e.g. SELECT key, rid FROM INDEX:Type[field]), read MAX/MIN values via the index shortcut, read and count TimeSeries samples, learn the type's record count, and delete index entries (DELETE FROM INDEX:Type[field]), which desynchronizes the index from the data and can defeat unique constraints. Index and type names needed for exploitation are discoverable because SELECT FROM schema:indexes is unfiltered. The issue affects both embedded and server deployments and all transports (HTTP, Bolt, Postgres, Gremlin) once a principal is bound. Fixed in 26.9.1.

ArcadeDB before 26.9.1 fails to enforce security-group types ACL entries for TimeSeries types because the ACL resolver builds permissions from bucket IDs, but TimeSeries types do not own normal record buckets. An authenticated low-privilege user can read or insert TimeSeries samples despite explicit deny rules by exploiting the missing type-name-based access check that causes permission lookups to fail open.

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.

ArcadeDB is a Multi-Model DBMS. Prior to 26.6.1, the IMPORT DATABASE statement in engine/src/main/java/com/arcadedb/query/sql/parser/ImportDatabaseStatement.java did not require administrative privileges and passed its source to integration/src/main/java/com/arcadedb/integration/importer/SourceDiscovery.java without validation. An authenticated user with SQL command access through /api/v1/command or /api/v1/query can supply HTTP or HTTPS destinations to make server-side requests to internal services, or file:// paths to read files accessible to the server process and ingest the results as queryable records. The XML importer also permits DTD processing and external entities, enabling entity expansion. The root-only /api/v1/server administration endpoint is not affected. The fix requires updateSecurity permission, blocks local-network import destinations by default through arcadedb.server.security.importBlockLocalNetworks, supports the arcadedb.server.security.importAllowedLocalPaths file allow-list, and disables XML DTD processing and external entities. This issue is fixed in version 26.6.1.

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.

ArcadeDB versions before 26.8.1 contain a server-side request forgery (SSRF) vulnerability in the OpenCypher LOAD CSV feature. This flaw allows authenticated attackers to craft queries that cause the server to fetch data from internal network addresses or cloud metadata endpoints, potentially exposing sensitive information. The vulnerability arises because the implementation does not properly validate HTTP/HTTPS URLs in LOAD CSV commands.

ArcadeDB versions before 26.8.1 contain a remote code execution vulnerability in the Gremlin query engine. The vulnerability arises because the ArcadeGremlin.executeStatement() method falls back to an insecure Groovy engine when a query with parameters does not parse as gremlin-lang. This fallback allows an authenticated user with any database role, including read-only, to execute arbitrary operating system commands as the server process user.

ArcadeDB (com.arcadedb) versions 26.7.3 and earlier fail to enforce the UPDATE_SCHEMA permission check when a DEFINE FUNCTION statement targets an already-existing function library. A user with only database access can add or overwrite SQL or Cypher functions in an existing library and persist the change, enabling tampering with admin-defined function logic. The issue is fixed in 26.8.1. (JavaScript functions still trigger the UPDATE_SECURITY check and are not affected.)