CVE-2026-106451 in lz4-java
Summary
by MITRE • 10/06/2026
yawkat LZ4 Java provides LZ4 compression for Java. From 1.7.0 until 1.11.4, net.jpountz.util.Native.load() uses File.createTempFile to create an exclusive temporary .lck file but derives the native-library path by removing the suffix, then FileOutputStream opens that predictable path without exclusive creation, allowing another local user with access to the same shared temporary directory to create or replace the library file before System.load() uses it. Successful exploitation depends on shared-directory permissions, host protections, and winning the race, and can execute native code as the victim; hardened systems may instead cause library loading to fail and fall back to Java implementations. Configurations using a system library, a private java.io.tmpdir, or Java-only implementations are not affected. This issue is fixed in version 1.11.4.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified in yawkat LZ4 Java versions from 1.7.0 through 1.11.4 represents a critical race condition and insecure temporary file handling flaw within the native library loading mechanism. The core technical deficiency lies in how the application manages the extraction of native libraries to the local filesystem for execution by the Java Virtual Machine. Specifically, the method net.jpountz.util.Native.load() initiates the process by creating an exclusive lock file using java.io.File.createTempFile with a .lck suffix. This step is designed to prevent concurrent access and ensure that only one instance of the application can load the library at a time. However, the subsequent derivation of the actual native library path involves simply removing this temporary extension from the filename generated for the lock file. The code then proceeds to open a FileOutputStream targeting this derived path without specifying exclusive creation flags or using atomic operations such as createNewFile in conjunction with proper permissions checks. This discrepancy creates a window of opportunity where an attacker can exploit the predictability and lack of exclusivity during the write operation.
This architectural flaw allows for a classic Time-of-Check to Time-of-Use race condition, which is categorized under CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition. Because the temporary directory path is often predictable or easily guessable by other users on the same system, and because the FileOutputStream does not enforce exclusive access at the file creation level, a local attacker with read-write permissions to that shared temporary directory can intervene between the moment the lock file is created and the moment the native library is written. By rapidly creating or replacing the target library file before the legitimate application writes its own version, an attacker can inject malicious code into the path intended for the LZ4 native implementation. This scenario aligns with ATT&CK technique T1059: Command and Scripting Interpreter if the injected payload executes arbitrary commands, or more broadly under privilege escalation vectors where local users escalate privileges by manipulating shared resources.
The operational impact of this vulnerability is severe, as successful exploitation results in the execution of native code within the context of the victim process. Since Java applications often run with elevated permissions relative to standard user processes, executing malicious native code can lead to full system compromise, data exfiltration, or lateral movement within a networked environment. The success of this attack is contingent upon several environmental factors, including whether the temporary directory has world-writable permissions, which is common in default configurations on many Unix-like systems such as /tmp. Additionally, host-level protections like SELinux or AppArmor may mitigate the risk by restricting file creation capabilities for unprivileged users, but these are not guaranteed defenses. If exploitation fails due to timing issues or system hardening, the application might experience a library loading failure and fall back to pure Java implementations of LZ4 compression, resulting in a denial of service rather than code execution, though this fallback behavior is not always present or reliable across all configurations.
Mitigation strategies must address both the immediate software defect and broader environmental security postures. The primary remediation is to upgrade yawkat LZ4 Java to version 1.11.4 or later, where the developers have corrected the file handling logic to ensure atomic operations and proper exclusivity during native library extraction. For systems unable to update immediately, administrators should enforce strict permissions on shared temporary directories such as /tmp by setting the sticky bit (chmod +t) which prevents users from deleting or renaming files owned by other users, thereby mitigating the ability of an attacker to replace the target file. Furthermore, configuring Java applications to use a private java.io.tmpdir directory that is not accessible to other local users eliminates the shared resource vector entirely. Utilizing system libraries via LD_LIBRARY_PATH instead of extracting them dynamically also removes this attack surface, as does relying solely on pure Java implementations if performance constraints allow. These measures collectively reduce the risk profile associated with dynamic native library loading in multi-user environments.