How severe is GHSA-48qw-824m-86pr?

GHSA-48qw-824m-86pr has a CVSS score of 7.7/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by GHSA-48qw-824m-86pr?

GHSA-48qw-824m-86pr affects the following packages: com.arcadedb:arcadedb-server (Maven). Ecosystems affected: Maven.

How do I fix GHSA-48qw-824m-86pr?

Update com.arcadedb:arcadedb-server to 26.7.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-48qw-824m-86pr is resolved across your whole dependency graph.

How do I detect GHSA-48qw-824m-86pr in my Maven dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for com.arcadedb:arcadedb-server. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-48qw-824m-86pr if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-48qw-824m-86pr?

O3 pinpoints whether GHSA-48qw-824m-86pr is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-48qw-824m-86pr actively exploited in the wild?

No public exploit code has been indexed for GHSA-48qw-824m-86pr yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-48qw-824m-86pr published, and has it been updated?

GHSA-48qw-824m-86pr was published on July 16, 2026 and was last updated on July 16, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

☕ Maven

GHSA-48qw-824m-86pr

HIGH

ArcadeDB: Privilege escalation via reader role in /api/v1/command JS scripting language — arbitrary host file read

Published

Jul 16, 2026

Updated

Jul 16, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

☕com.arcadedb:arcadedb-server

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.

Description

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:

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.
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 (allowCreateProcess(false)), so the confirmed impact is host file read, not OS command execution. Confidentiality: High. Integrity/Availability: None.

This is a distinct entry point and root cause from CVE-2026-44221, CVE-2026-54076 and CVE-2026-54077, and is reproducible on builds that already contain those fixes.

Patches

The fix is applied in the engine so it covers every entry point (HTTP command, HA-forwarded commands, MCP analyze), not only the HTTP handler:

Polyglot script execution now requires the updateSecurity database-administrator permission on command, analyze and registerFunctions. The check runs on the request thread that carries the authenticated user and is a no-op in embedded mode and internal/system contexts (schema load, HA replication apply).
The GraalVM host-access policy now denies access to java.lang.Class, java.lang.ClassLoader and java.lang.reflect members, closing the reflection escape that bypassed allowedPackages - even for authorized administrators - while leaving normal method calls on bound objects and explicit Java.type(...) lookups (governed by allowedPackages) working.

Workarounds

Until upgraded, do not grant command/query access on the HTTP API to untrusted users, and treat any account that can reach /api/v1/command as capable of code execution. Note that after the fix, non-administrator accounts can no longer run js/polyglot scripts over HTTP.

Credit

Reported by @kyojune76.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
☕Maven	`com.arcadedb:arcadedb-server`	all versions	26.7.1

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for com.arcadedb:arcadedb-server. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update com.arcadedb:arcadedb-server to 26.7.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-48qw-824m-86pr is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-48qw-824m-86pr is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-48qw-824m-86pr. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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

O3 Security · Impact-Aware SCA

Is GHSA-48qw-824m-86pr in your dependencies?

O3 detects GHSA-48qw-824m-86pr across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works

GHSA-48qw-824m-86pr

Blast Radius

Description

Impact

Patches

Workarounds

Credit

Affected Packages

Detection & mitigation playbook

Detect

Fix

Workarounds

How O3 protects you

Frequently Asked Questions

Is GHSA-48qw-824m-86pr in your dependencies?