CVE-2026-106451: 
Java vulnerability analysis and mitigation

CVE-2026-106451 is a TOCTOU (Time-of-Check Time-of-Use) race condition vulnerability in yawkat's lz4-java library that allows a local attacker to replace a native library file in a shared temporary directory, potentially executing arbitrary native code as the victim process. It affects org.lz4:lz4-java versions 1.7.0 through 1.11.3 and at.yawk.lz4:lz4-java versions up to 1.11.3. The vulnerability was published on October 6, 2026, and fixed in version 1.11.4. It carries a CVSS v4.0 base score of 7.3 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is a combination of CWE-367 (TOCTOU Race Condition), CWE-377 (Insecure Temporary File), and CWE-379 (Temporary File in Insecure Directory). In net.jpountz.util.Native.load(), a .lck lock file is safely created via File.createTempFile() with a random name and exclusive creation, but the actual native library path is derived by stripping the .lck suffix — and that derived path is then opened with new FileOutputStream(tempLib), which uses O_CREAT|O_TRUNC without exclusive creation and follows symlinks. An attacker monitoring the shared java.io.tmpdir can observe the .lck file appearing, pre-create or replace the corresponding library file, and have their malicious native code loaded by the victim's JVM via System.load(). Exploitability depends on host hardening: with fs.protected_regular = 0, full code execution is possible; with fs.protected_regular >= 1 (default on many systemd-based Linux distributions), the open fails and the library falls back to Java implementations, limiting impact to denial of service. The vulnerable behavior was introduced in commit c3ddae5 (lz4-java 1.7.0) (GitHub Advisory, Patch Commit).

Successful exploitation allows a local attacker with write access to the same shared temporary directory to execute arbitrary native code with the privileges of the victim Java process, enabling full confidentiality, integrity, and availability compromise of that process. On hardened systems where exploitation of the race fails, the attacker can still cause the native library to fail to load, forcing fallback to slower Java implementations or causing application errors (denial of service). Configurations using a system-installed native library on java.library.path, a private per-user java.io.tmpdir (e.g., via systemd PrivateTmp), or Java-only implementations are not affected (GitHub Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at the time of disclosure. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires local access to the same shared temporary directory, the ability to win a timing race, and favorable host configuration (e.g., fs.protected_regular = 0 or a tmpdir without the sticky bit) (GitHub Advisory, Red Hat Bugzilla).

1. Reconnaissance: Identify a target system running a Java application that uses org.lz4:lz4-java (versions 1.7.0–1.11.3) with a shared, world-writable java.io.tmpdir (e.g., /tmp with the sticky bit, or a container-shared directory without it). Confirm that no system-installed liblz4-java is present on java.library.path.
2. Monitor the temporary directory: As a local user, use inotifywait or a polling loop to watch java.io.tmpdir for the creation of a file matching the pattern liblz4-java-*.{so,dll,dylib}.lck.
3. Race to create the library file: Upon detecting the .lck file, immediately create or place a malicious native library at the corresponding path (the .lck filename with the .lck suffix removed), e.g., liblz4-java-<random>.so. On systems with fs.protected_regular = 0, pre-create a world-writable file at that path before the victim process opens it.
4. Inject malicious native code: Ensure the file placed at the library path contains a valid shared library with a malicious payload (e.g., a constructor function that spawns a reverse shell or copies an SSH key).
5. Trigger library load: Wait for the victim Java process to call System.load() on the attacker-controlled file. If the race is won, the malicious native library is loaded into the victim's JVM and the payload executes with the victim process's privileges (GitHub Advisory).

• File System: Unexpected files matching liblz4-java-*.{so,dll,dylib} in /tmp or the configured java.io.tmpdir owned by a user other than the Java process owner; presence of .lck files without a corresponding library file (or vice versa) in the temporary directory.
• Process: Unusual child processes spawned by the Java process (e.g., /bin/bash, curl, wget, python) shortly after JVM startup or library initialization; unexpected network connections originating from the Java process.
• Logs: Java application logs showing ExceptionInInitializerError: Cannot unpack liblz4-java or fallback messages indicating native library load failure; OS audit logs (auditd) recording file creation events in /tmp by a user other than the application owner for files matching liblz4-java-*.
• Network: Outbound connections from the Java process to unexpected external hosts immediately following application startup.

Upgrade lz4-java to version 1.11.4, which fixes the issue by writing the native library directly to a file created by File.createTempFile() (with a random name and exclusive creation), eliminating the predictable intermediate path and the .lck lock file mechanism (GitHub Release, Patch Commit). If immediate upgrade is not possible, configure a private per-user temporary directory (e.g., via systemd PrivateTmp=true or setting java.io.tmpdir to a directory writable only by the application user), or install liblz4-java as a system library on java.library.path. Alternatively, if native performance is not required, configure the application to use Java-only LZ4 implementations (GitHub Advisory).