The vulnerability in the yawkat LZ4 Java library is a race condition and improper file handling flaw (CWE-367, CWE-377, CWE-379). It occurs while the library loads a native component by first creating a lock file in the system temporary directory and then writing the native library to a predictable path derived from that file. Because the subsequent file creation does not use exclusive flags, another local user can overwrite the native library before it is loaded. If successfully replaced, the attacker can supply forged native code that will execute with the same privileges as the Java process, potentially granting local code execution and privilege escalation. This flaw is mitigated by hardened systems that detect tampering and fall back to a pure Java implementation, which prevents exploitation without code changes.

The issue affects the yawkat LZ4 Java library, versions 1.7.0 through 1.11.4 inclusive. Systems using an external native library, a private java.io.tmpdir setting, or the Java-only implementation are not vulnerable. The fix was introduced in 1.11.4.

With a CVSS v3 score of 7.3, the vulnerability has a medium to high severity and involves race condition (CWE-367), improper temporary file handling (CWE-377), and untrusted resource usage (CWE-379). EPSS data is not available, and the vulnerability is not listed in CISA KEV. Successful exploitation requires that the application runs with write access to the shared temporary directory, that the directory is not locked by system protections, and that the attacker can outpace the race condition. If these conditions are met, native code can be executed under the process’s user. Hardened configurations that validate the library path or roll back to Java-only code effectively mitigate the risk.