EUVD-2025-210362
GHSA-6f68-j9jr-9q2w
Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Attacker must be a co-tenant with shared-/tmp access (AV:L, PR:L); planted artifacts persist without a tight race (AC:L); code runs in another user's JVM (S:C) yielding full C/I/A impact.
Primary rating from Vendor (certcc).
CVSS VectorVendor: certcc
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Lifecycle Timeline
3DescriptionCVE.org
The default JVM can access files and directories under /tmp/ including the $TemporaryDirectory of other users on the same cloud instance (/tmp/UserTemporaryFiles/). The -init file for the the JVM initialization exists in the vulnerable directory during the startup of the JVM. An attacker with access to the shared /tmp/ space can preemptively create or replace .jar files or directories (via the -init file) that the victim JVM will resolve first in its classpath. By strategically placing a malicious version of a commonly used library (e.g., commons-io) in a location that is included in the classpath before the legitimate version, an attacker can cause the JVM to load the malicious class during startup, thereby executing the attacker's code.
AnalysisAI
Code execution against the shared multi-tenant Java runtime in Wolfram Cloud 14.2 is possible because the default JVM resolves classpath artifacts from a world-accessible /tmp/ location shared across tenants on the same cloud instance. A co-tenant attacker who can write to /tmp/UserTemporaryFiles/ can plant a malicious .jar or directory referenced by the JVM's -init startup file so the victim JVM loads attacker-controlled classes ahead of the legitimate library, executing code in the victim's session. No public exploit identified at time of analysis, though CVSS rates the issue 9.6 with a scope change reflecting cross-user/cross-tenant impact.
Technical ContextAI
The flaw lives in how the default JVM in Wolfram Cloud handles initialization on a shared host. During JVM startup a -init file located under the shared /tmp/ tree (specifically /tmp/UserTemporaryFiles/) drives classpath resolution, and because /tmp/ is readable and writable across users/tenants on the same instance, one tenant can influence the directories and JAR files another tenant's JVM consults first. This is a classpath/search-path hijack: a malicious copy of a commonly imported library (the disclosure cites commons-io) placed earlier in the resolution order is loaded instead of the genuine one. No CWE was assigned in the input, but the root cause maps to the Untrusted/Uncontrolled Search Path Element class (CWE-426/CWE-427) compounded by insecure use of a shared temporary directory (CWE-377); the affected CPE is cpe:2.3:a:wolfram_research_inc.:cloud and EUVD scopes it to Cloud 14.2.
RemediationAI
No vendor-released patch or fixed version was identified at time of analysis, so remediation centers on compensating controls. The most direct mitigation is to break the shared-/tmp/ trust boundary: configure per-user/per-tenant private temporary directories (e.g., set a tenant-specific java.io.tmpdir/$TemporaryDirectory and isolate /tmp/UserTemporaryFiles/ per user) so one tenant cannot read or write another's JVM startup artifacts - the trade-off is configuration/operational overhead and possible breakage of tools that assume a shared /tmp. Where feasible, restrict permissions on /tmp/UserTemporaryFiles/ (mode 1777 sticky-bit alone is insufficient because the attack relies on creating new files, so use per-user subdirectories with 0700), and pin/validate the JVM classpath so the -init file and trusted libraries resolve from a protected, non-shared path ahead of any /tmp-derived entries. Reduce blast radius by moving high-value tenants to single-tenant instances. Monitor the CERT/CC note (https://www.kb.cert.org/vuls/id/553375) and the disclosure (https://github.com/PeterRoberge/vulnerability-wolfram-cloud-14.2/blob/main/disclosure.md) for an official fixed build, and apply it once Wolfram Research publishes one.
In Splunk Enterprise versions below 9.0.7 and 9.1.2, Splunk Enterprise does not safely sanitize extensible stylesheet la
A command injection vulnerability was found in the web administration console in SoftNAS Cloud before 4.0.3. Rated criti
An issue was discovered in TigerGraph Enterprise Free Edition 3.x. Rated high severity (CVSS 8.8), this vulnerability is
OpenStack Identity (Keystone) before 2013.2.4, 2014.1 before 2014.1.2, and Juno before Juno-2 does not properly handle c
An authentication bypass vulnerability in MobileIron Core & Connector versions 10.3.0.3 and earlier, 10.4.0.0, 10.4.0.1,
SoftNAS Cloud 4.2.0 and 4.2.1 allows remote command execution. Rated critical severity (CVSS 9.8), this vulnerability is
An issue was discovered in TigerGraph Enterprise Free Edition 3.x. Rated medium severity (CVSS 4.9), this vulnerability
Heap-based buffer overflow in the fcgid_header_bucket_read function in fcgid_bucket.c in the mod_fcgid module before 2.3
Fabasoft Cloud Enterprise Client 23.3.0.130 allows a user to escalate their privileges to local administrator. Rated hig
In Splunk Enterprise versions below 9.2.2, 9.1.5, and 9.0.10 and Splunk Cloud Platform versions below 9.1.2312.109 and 9
Improper handling of insufficient permissions or privileges vulnerability in Samsung Data Store prior to version 5.2.00.
Implicit Intent hijacking vulnerability in Samsung Cloud prior to version 5.2.0 allows attacker to get sensitive informa
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today