Path Traversal Vulnerability in Deep Java Library (DJL) and Its Impact on Java AI Development

Deep Java Library (DJL) is an open source deep learning framework that brings AI capabilities to Java developers without requiring a shift to Python. It provides an intuitive, high-level API for building, training, and deploying machine learning models, supporting deep learning engines like TensorFlow, PyTorch, and MXNet. While not as widely adopted as Python-based frameworks, DJL is gaining traction in Java-based AI applications, especially in enterprise software, cloud environments, and financial services. It’s also used in LangChain4j, specifically in the langchain4j-embeddings package, which enables Java developers to leverage AI-powered embeddings for natural language processing and retrieval-augmented generation (RAG) applications. However, as with any AI library, security is a critical concern. CVE-2025-0851 is a newly identified vulnerability that raises important questions about potential risks in DJL’s ecosystem. Let’s break down what this CVE means, how it affects DJL users, and what you can do to stay secure.

CVE-2025-0851 explained

CVE-2025-0851 is a path traversal vulnerability in Deep Java Library (DJL) that could allow an attacker to manipulate file paths and gain unauthorized access to restricted files on a system. Path traversal occurs when an application improperly validates file paths, enabling attackers to navigate the file system and access sensitive files outside the intended directory. This vulnerability can be exploited to read confidential data, modify system configurations, or execute arbitrary code under certain conditions. Since DJL is used for loading and processing machine learning models, applications handling untrusted input for file operations are particularly at risk. If left unpatched, CVE-2025-0851 could expose systems to data leaks, privilege escalation, or remote code execution, making it crucial for developers to assess their usage of DJL and apply necessary mitigations.

Absolute Path Traversal

The specific problem for DJL versions below 0.31.1 is not a regular path traversal, where and attacker can use ../ but an absolute path traversal. This happened in the utility files that unpack Tar and Zip files, which are used, for instance, for loading models. In both cases, every entry in the archive is getting checked like this:

String name = removeLeadingFileSeparator(entry.getName());
if (name.contains("..")) {
   throw new IOException("Malicious zip entry: " + name);
}
set.add(name);
Path file = dest.resolve(name).toAbsolutePath();

static String removeLeadingFileSeparator(String name) {
   int index = 0;
   for (; index < name.length(); index++) {
       if (name.charAt(index) != File.separatorChar) {
           break;
       }
   }
   return name.substring(index);

The normalization relies on the removeLeadingFileSeperator and the check if the string contains “..”. A regular path traversal seems to be covered, although we can argue if a static check on “..” is the best way to do this. The actual problem is in removeLeadingFileSeperator(). This function relies on the separtorChar which can be different per operating system. 

For instance, if a Zip archive is created on Linux using a / and used in a Windows environment that uses a \, the leading slash will not be removed. This means on Windows that is the destination path is \tmp and the entry name is  /Windows/System32/evil.lib the entry will be seen as an absolute path resulting in the file being placed at C:\Windows\System32\evil.lib. The intended destination (\tmp ) will be ignored because the entry destination is considered an absolute path, not a relative one. 

The code example below run on a Windows 11 machine proves this statement:

public class Main
{
   public static void main(String[] args) throws Exception {
       Path dest = Path.of("\\tmp");
       String input = "/Windows/System32/evil.lib";

       String name = removeLeadingFileSeparators(input);
       if (name.contains("..")) {
           throw new IOException("Malicious zip entry: "+ name);
       }
       Path file = dest.resolve(name).toAbsolutePath();
       System.out.println("Resolved to " + file);

   }

   static String removeLeadingFileSeparators(String name) {
       int index = 0;
       for (; index < name.length(); index++) {
           if (name.charAt(index) != File.separatorChar) {
               break;
           }
       }

       return name.substring(index);
   }

Output:

Resolved to C:\Windows\System32\evil.lib
Process finished with exit code 0

This shows if a zip or tar file created on Linux can escape the sanitization step on Windows. Therefore, crafting a targeted zip or tar file gives the opportunity to overwrite or insert files at arbitrary locations on the host machine. 

This can lead to all sorts of problems like:

• Overwriting System Files

• Planting Malicious Executables of Libraries

• Altering Application or Configuration Data

• Escalation of Privileges

• and so on.

Depending on the OS this can potentially also work the other way around as Linux and BSD-based systems will not remove a leading ”\”.  It depends on the OS implementation if it interprets a filename like “\something\evil.lib” as an absolute or relative path. Nevertheless, this path traversal vulnerability should be taken care of.

Remediation

Updating DJL to 0.31.1 or above solves this specific CVE. DJL versions 0.31.1 and later address path traversal vulnerabilities using the normalize() function on Path. This update is reflected in this specific GitHub commit. If you cannot update, pleas make sure to avoid using zip or tar files with unknown content.

Snyk can also help you identify and remediate vulnerabilities like this one, not only in your supply chain but also in your custom code and more. Below, you see the Snyk plugin within the IntelliJ development environment. It detected the vulnerability in my manifest file and showed an available update. The identified issue can be resolved by upgrading to version 0.31.1 or any later version. This update process can be conveniently executed with a single click directly from the notification within IntelliJ.

This vulnerability highlights the importance of addressing supply chain security. If you aren't already, consider scanning your applications with Snyk to protect all application components.