If successful, the attacker can replace the intended native library with malicious code, which is then loaded by the victim's JVM via System.load(), executing with the victim's privileges. The vulnerability depends on host-level protections; systems with fs.protected_regular or fs.protected_symlinks enabled may mitigate the code execution vector but remain susceptible to a denial of service if the library fails to load. This vulnerability impacts lz4-java versions 1.7.0 through 1.8.1 and 1.11.3 and earlier.

Impact

Successful exploitation allows a local attacker to execute arbitrary code within the context of the vulnerable Java application. In environments where OS-level protections (such as hardened symlink or file creation settings) are disabled, or in shared temporary directories without sticky bits (including certain container configurations), the risk of privilege escalation is significant. If exploitation is prevented by OS protections, attackers can still trigger a denial of service by causing the library loading process to fail, forcing the application to fall back to less performant Java implementations or crash.

Recommendation

1. Patch immediately by upgrading to lz4-java version 1.11.4 or later, which utilizes secure temporary file creation.
2. For applications where patching is not immediately feasible, configure the application to run with a dedicated, private java.io.tmpdir that is restricted to the application service user.
3. Alternatively, install the native liblz4-java package at the OS level and ensure it is available on the java.library.path, which bypasses the insecure extraction logic entirely.