Wolfram Cloud CVE-2025-11919

Exploitation requires the attacker to be an authenticated co-tenant with read/write access to the shared /tmp/ space - specifically /tmp/UserTemporaryFiles/ - on the same Wolfram Cloud instance as the victim (PR:L confirms an authenticated, non-elevated account is needed). The attacker must be able to create or replace .jar files or directories that the victim JVM's -init startup file references so the malicious artifact (e.g., a fake commons-io) precedes the legitimate library in the classpath. Limiting factors: the vulnerability only applies to multi-tenant/shared-instance deployments of Cloud 14.2 (single-tenant or per-user-isolated /tmp deployments are not exposed), the malicious files must be in place before the victim JVM initializes, and the attacker needs a valid account on the instance - it is not exploitable by an anonymous internet attacker despite the AV:N labeling.

Signals are mixed and warrant scrutiny. The published CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N, 9.6) drives a critical score largely from S:C and high confidentiality/integrity impact, but the description explicitly requires the attacker to already have access to the shared /tmp/ space on the same cloud instance - that is local/co-tenant access, not true network-remote exploitation, so the AV:N labeling likely overstates reach and AV:L is more defensible. No EPSS score, KEV listing, SSVC decision, or confirmed POC was provided, so automatability and active-exploitation status are unknown. The realistic priority is high for organizations running shared/multi-tenant Wolfram Cloud 14.2 (a co-tenant can pivot into another tenant's execution context), but the prerequisite of an authenticated account with shared-tmp access and the need to win placement before victim JVM startup temper the practical exploitability relative to the raw 9.6.

An attacker provisions a low-privilege account on a shared Wolfram Cloud 14.2 instance and writes a malicious commons-io JAR (or a directory referenced by the -init file) into the world-accessible /tmp/UserTemporaryFiles/ space. When a victim tenant starts a JVM, it resolves the attacker's planted artifact first in its classpath and loads the malicious class during initialization, running the attacker's code in the victim's session context. The shared-/tmp access is the only prerequisite; no public exploit was provided, but the disclosure document describes the technique in detail.