External risk intelligence

JVM Local Temporary Directory Preemption Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.6)

CVE-2025-11919

The vulnerability requires a local attacker to have access to the shared /tmp/ directory on the same cloud instance or host to perform file preemption. It is a local file system and configuration issue occurring during JVM startup, not a service or network-facing interface accessible from the public internet.

Halo Surface Signal: 1 out of 5 — much less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A security vulnerability has been identified in Java Virtual Machine (JVM) startup processes, specifically affecting how temporary files are handled on shared cloud instances. This could allow an attacker with limited access to the temporary file system to introduce malicious code that executes when the JVM starts. The main concern is confirming relevance and exposure.

Attackers can inject code during startup.
Shared temporary files are a risk.
Confirm exposure and relevance.

Attack Path

How an attacker could exploit the issue

An attacker with access to a shared temporary file directory can trick a Java Virtual Machine (JVM) into loading malicious code during startup. By creating or replacing specific initialization files or libraries in the JVM's classpath before the legitimate ones, an attacker can cause the JVM to execute their own code instead of the intended program.

Local access to shared files required.
Malicious file placement during JVM startup.
Arbitrary code execution can occur.

Live Threat

Current exploitation, exposure, and threat context

An attacker with access to a shared `/tmp/` directory on the same cloud instance could potentially execute malicious code when a vulnerable Java Virtual Machine (JVM) starts up. This occurs by replacing or creating specific initialization files, causing the JVM to load an attacker-controlled library instead of the legitimate one.

JVM initialization files.
Preemptively replacing shared files.
Malicious code execution during startup.

Operational Fix

Recommended remediation, mitigation, and detection steps

Given the JVM's reliance on shared temporary directories, application owners and infrastructure teams are likely responsible for addressing this vulnerability. The immediate practical step is to identify all instances of the affected JVM, confirm their reachability and criticality, and then engage the accountable owner to plan remediation.

Confirm asset inventory and ownership.
Verify JVM startup classpath configuration.
Plan risk-based remediation strategy.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is the JVM mentioned in CVE-2025-11919?

The Java Virtual Machine (JVM) is a core software engine that allows computer systems to run Java-based applications. It acts as an abstraction layer, executing bytecode regardless of the underlying hardware. In cloud environments, multiple users or processes often share the same host, relying on the JVM to manage memory and resources securely while isolating temporary files required during startup.

How does CVE-2025-11919 cause a security weakness?

This vulnerability involves an insecure file handling flaw. Because the JVM initializes using a shared temporary directory, an attacker can perform a 'preemption' attack. By placing a malicious file in a location the JVM reads during startup, the attacker tricks the application into loading their code instead of the legitimate library, effectively hijacking the execution process.

Do I need local access to trigger CVE-2025-11919?

Yes. The trigger requires an attacker to have the ability to place files into a shared temporary directory on the same cloud instance or host as the target JVM. Accessing a remote website or network interface will not trigger this vulnerability. The risk is specifically present when untrusted parties can write to the same file system location the JVM uses for its startup configuration.

Is my system at risk according to Halo Surface Signal?

Halo Surface Signal identifies this as very unlikely for internet-facing systems because the vulnerability is a local file system issue, not a network-facing service. Exposure is restricted to environments where attackers share the same host file system. If your JVM instances are isolated from other users' access, the potential for this specific preemption technique is significantly lowered.

What should I do first to address CVE-2025-11919?

Start by identifying all JVM instances within your environment and mapping them to their respective cloud hosts. Review your configuration to determine if these instances use shared temporary directories that are accessible to other local users. Once you have an inventory of potentially exposed assets, prioritize them for review to verify their classpath configurations and local access controls.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.