CVE-2025-11919: JVM Classpath Manipulation RCE Vulnerability

CVE-2025-11919 Overview

CVE-2025-11919 is a classpath hijacking vulnerability affecting Wolfram Cloud 14.2. The default Java Virtual Machine (JVM) accesses files under /tmp/, including the $TemporaryDirectory of other users on the same cloud instance at /tmp/UserTemporaryFiles/. During JVM startup, the -init file resides in this shared, writable directory. An attacker with access to /tmp/ can preemptively create or replace .jar files that the victim JVM resolves first in its classpath. Placing a malicious version of a common library such as commons-io earlier in the classpath causes the JVM to load attacker-controlled classes at startup.

Critical Impact
Authenticated local users on a shared Wolfram Cloud instance can execute arbitrary code inside another user's JVM context by planting malicious JARs in the shared /tmp/ directory.

Affected Products

Wolfram Cloud 14.2
Shared cloud instances relying on the default JVM $TemporaryDirectory under /tmp/UserTemporaryFiles/
Java runtimes launched with classpath entries resolving into world-accessible /tmp/ locations

Discovery Timeline

2026-06-26 - CVE-2025-11919 published to the National Vulnerability Database
2026-06-26 - Last updated in NVD database

Technical Details for CVE-2025-11919

Vulnerability Analysis

The flaw is a classpath injection issue rooted in insecure use of a shared temporary directory. On multi-tenant Wolfram Cloud instances, each user's $TemporaryDirectory lives under /tmp/UserTemporaryFiles/, which is reachable by any local account. The JVM initialization sequence references an -init file stored in that directory, and the classpath includes locations under /tmp/ before authoritative library paths.

Because the JVM resolves the first matching class name on the classpath, an attacker who plants a rogue JAR earlier in the search order executes code inside the victim JVM. This qualifies as insecure permissions combined with untrusted search path behavior, enabling code injection at process startup.

Root Cause

The root cause is placement of JVM initialization artifacts and classpath entries in a world-accessible directory (/tmp/UserTemporaryFiles/) without per-user isolation. The JVM trusts files in this location and loads them before verified library sources. No integrity check gates the -init file or the JAR resolution order.

Attack Vector

An authenticated user on the shared cloud instance writes a malicious commons-io (or similarly named) JAR into a location that the victim's JVM traverses first. When the victim launches a Wolfram kernel or triggers JVM startup, classes from the attacker's JAR load into the victim's process. Execution occurs under the victim's identity, breaking tenant isolation and compromising confidentiality and integrity. See the GitHub Vulnerability Disclosure and CERT Vulnerability Note #553375 for exploitation details.

No verified public proof-of-concept code is available at time of writing. Refer to the linked disclosure for reproduction steps.

Detection Methods for CVE-2025-11919

Indicators of Compromise

Unexpected .jar files owned by non-service accounts within /tmp/UserTemporaryFiles/ or other /tmp/ subdirectories referenced by the JVM classpath
Modifications to -init files in shared temporary directories outside a legitimate JVM startup sequence
JVM processes loading classes from /tmp/ paths not managed by the platform installer

Detection Strategies

Monitor file creation and rename events in /tmp/UserTemporaryFiles/ using Linux audit rules on open, creat, and rename syscalls
Alert when Java processes resolve classes from user-writable directories by inspecting -verbose:class output or JVM audit logging
Correlate authenticated user sessions with write activity in shared temporary paths preceding another user's kernel launch

Monitoring Recommendations

Baseline the expected contents of /tmp/UserTemporaryFiles/ and flag deviations, especially new JARs and executable content
Track parent-child process relationships for Java kernels launched by the Wolfram Cloud runtime to detect anomalous class loads
Retain JVM stdout and stderr for review of ClassNotFoundException, NoClassDefFoundError, or unexpected class version mismatches that indicate hijack attempts

How to Mitigate CVE-2025-11919

Immediate Actions Required

Restrict permissions on /tmp/UserTemporaryFiles/ so each user's subdirectory is only readable and writable by that user (mode 0700)
Remove /tmp/-derived paths from the JVM classpath and relocate $TemporaryDirectory to a per-user, non-shared location
Audit existing /tmp/UserTemporaryFiles/ contents for rogue JARs or tampered -init files before applying isolation controls

Patch Information

No vendor patch reference is included in the NVD record at time of publication. Consult the GitHub Vulnerability Disclosure and CERT Vulnerability Note #553375 for current vendor status and upgrade guidance for Wolfram Cloud 14.2.

Workarounds

Move $TemporaryDirectory outside /tmp/ to a user-owned path such as $HOME/.wolfram/tmp with mode 0700
Launch the JVM with an explicit -classpath that excludes any world-writable directories and pins library versions to trusted paths
Enforce filesystem namespaces or per-user tmp mounts (for example, systemdPrivateTmp=yes) so each Wolfram session sees an isolated /tmp/

bash

# Configuration example
# Enforce per-user temporary isolation and remove /tmp from classpath
chmod 0700 /tmp/UserTemporaryFiles/$USER
export TMPDIR="$HOME/.wolfram/tmp"
mkdir -p "$TMPDIR" && chmod 0700 "$TMPDIR"
java -Djava.io.tmpdir="$TMPDIR" \
     -classpath "/opt/wolfram/lib/*" \
     com.wolfram.Kernel