Open-Source Security Intelligence

Know every vulnerability
before it knows you.

DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.

Checkout DevGuard View on GitHub

GHSA-48qw-824m-86pr

HighCVSS 7.7 / 10

Published Jul 16, 2026·Last modified Jul 16, 2026

Affected Components(0)

No affected components available

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.

Risk Scores

Base Score

7.7

The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker needs basic access or low-level privileges. No user interaction is needed for the attacker to exploit this vulnerability. The vulnerability can affect other systems as well, not just the initial system. There is a high impact on the confidentiality of the information.

Threat Intelligence

7.1

Exploitation activity has been observed. Apply available patches or mitigations urgently.

EPSS

N/A

Probability that this vulnerability will be exploited in the wild within the next 30 days.

Exploit

Not available

We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.

Browse More

High severity

Scan your project

Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.