CVE-2026-86071: Path Traversal Vulnerability in Junrar Archive Library

CVE-2026-86071 designates a directory traversal vulnerability in Junrar, an open-source Java library utilized for reading and extracting RAR archives. The vulnerability exists within the extraction pipeline, specifically inside the component responsible for creating localized file structures on the filesystem. When processing a RAR archive containing specialized entry filenames, the library fails to restrict directory creation to the intended extraction root directory.

This security flaw belongs to the class of CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). The attack surface is exposed to any application that accepts untrusted RAR files and uses Junrar to extract them. Typical deployment scenarios include automated mail attachments scanners, file upload portals, and backup restoration services running in enterprise environments.

While traditional path traversal vulnerabilities permit attackers to write arbitrary files or execute code, this specific vulnerability is bounded by a logical validator. The filesystem writes are restricted to directory creation operations, as final file creations undergo subsequent canonicalization checks. Consequently, the operational impact is restricted to directory creation, directory structure pollution, and service disruption via directory squatting.

This issue was addressed in the 7.6.1 release of the library on July 21, 2026. Security teams are advised to review downstream dependencies to identify usage of affected Junrar versions.

The root cause of CVE-2026-86071 lies in a logical discrepancy between the initial path validation phase and the iterative directory creation process inside the LocalFolderExtractor class. To prevent arbitrary file writes outside the target sandbox, the library first verifies that the canonical path of the resolved file starts with the canonical path of the destination directory. This validation routine utilizes the getCanonicalPath() method to resolve symbolic links and relative path elements.

An attacker bypasses this verification check by designing a path containing relative traversal sequences that navigate out of the target sandbox and subsequently return to it. For example, a path structured as ../../extract_evil/../../destination/safe_file resolves canonicalization to /destination/safe_file when evaluated against the base directory. Because the canonicalized path starts with the destination directory, the path validation routine registers the path as safe and permits execution to continue.

Following validation, the library attempts to dynamically construct any missing parent directories by calling the makeFile method. This method processes the raw, unnormalized path string instead of the validated canonical path. It splits the string on the forward slash character to create an array of individual directory names, then sequentially iterates through this array to build and create each directory on the filesystem.

During this iterative assembly, the library sequentially appends each unnormalized directory segment—including relative sequences—to the destination path. The filesystem executes the mkdir() command on each resulting intermediate directory. Because these intermediate directories are not subjected to canonicalization checks or sandbox containment checks during this step, the library creates directories in locations outside the authorized destination boundary.

To examine the vulnerability, analyze the vulnerable implementation of the makeFile method inside LocalFolderExtractor.java. The vulnerable version uses string splitting and unnormalized string concatenation to create parent directories. The implementation is shown below:

// Vulnerable Code: LocalFolderExtractor.java
private File makeFile(final File destination, final String name) throws IOException {
    final String[] dirs = name.split("/");
    String path = "";
    final int size = dirs.length;
    if (size == 1) {
        return new File(destination, name);
    } else if (size > 1) {
        for (int i = 0; i < dirs.length - 1; i++) {
            // Concatenating unnormalized traversal sequences directly
            path = path + File.separator + dirs[i];
            File dir = new File(destination, path);
            dir.mkdir(); // Executes mkdir on unvalidated path segments
        }
        path = path + File.separator + dirs[dirs.length - 1];
        final File f = new File(destination, path);
        f.createNewFile();
        return f;
    } else {
        return null;
    }
}

The vulnerability is mitigated in commit e6e333b195a1e3ad271a18fd79d8ac1eb5289343 by adopting standard Java NIO.2 APIs. This modern approach resolves paths logically before any physical directory operations occur on the local filesystem. The patched implementation is presented below:

// Patched Code: LocalFolderExtractor.java
private File createFile(final FileHeader fh, final File destination) throws IOException {
    // ... (validation logic) ...
    if (!f.exists()) {
        try {
            // Call normalize() to collapse redundant relative path components
            f = makeFile(f.toPath().normalize());
        } catch (final IOException e) {
            logger.error("error creating the new file: {}", f.getName(), e);
        }
    }
    return f;
}
 
private File makeFile(final Path file) throws IOException {
    if(file.getParent() == null) return null;
    // Securely creates directories using normalized path structure
    Files.createDirectories(file.getParent());
    return file.toFile();
}

The replacement of the manual loop with f.toPath().normalize() ensures that all redundant path segments, such as . and .., are resolved syntactically prior to directory creation. If the input contains traversal elements, the normalize() method resolves the path to its clean absolute representation. Consequently, Files.createDirectories() only acts on the legitimate destination directory structure, leaving no opportunity for intermediate directories to escape the sandbox.

Exploitation of CVE-2026-86071 requires the creation of a malformed RAR archive containing a specifically structured directory path. An attacker must construct an entry where the path moves outward from the intended root folder and then pivots back inward. The structure requires matching traversal steps to balance the final path and ensure it starts with the valid destination directory when canonicalized.

An attacker begins by identifying a target folder to create on the host system, such as /tmp/malicious_dir. Assuming the target extraction directory is /var/app/storage/extract, the attacker designs a relative path like ../../../../tmp/malicious_dir/../../../../var/app/storage/extract/valid_file.txt. The application must receive this archive file through an exposed ingestion vector, such as an HTTP file upload interface or an email processing queue.

When the victim application extracts the archive, the validation logic compares the canonical form of the target file path against the expected root directory. Because both resolve within the authorized boundary, validation is successful. However, during the sequential creation of the directory tree, the application issues filesystem commands to create the intermediate directory /tmp/malicious_dir. This occurs without raising an application-level exception, allowing the overall extraction process to complete silently.

While standard security tooling may flag plain traversals, nested loop traversals that resolve back into the sandbox often bypass basic static signature checks. This increases the probability of successful exploitation if input checking depends entirely on end-state canonical validation.

The security impact of CVE-2026-86071 is assessed as low, with a CVSS v3.1 base score of 3.7. The vector string is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N. Because the vulnerability does not allow arbitrary file writes or arbitrary code execution, the direct compromise of system confidentiality and availability is prevented.

Despite the low severity score, the ability to create arbitrary directories poses operational risks in specific environments. An attacker can perform directory squatting or pre-create directories that are expected to be private or owned by other processes. On shared host configurations, directory creation can disrupt existing storage mappings, fill up local inode tables, or trigger logical errors in other processes that monitor filesystem changes.

Furthermore, directory creation can be used in multi-stage exploitation scenarios. For example, if another system service relies on the non-existence of a specific folder to perform an installation or initialization routine, pre-creating that folder can disrupt the service or alter its logical flow. There is currently no evidence of active exploitation of this vulnerability in the wild, and it is not listed in CISA's Known Exploited Vulnerabilities catalog.

This is not a traditional Zip Slip vulnerability because files themselves cannot be written outside the target directory, making it a unique logical variant of CWE-22.

The definitive remediation for this vulnerability is to upgrade the Junrar dependency to version 7.6.1 or later. This version replaces the legacy directory-creation logic with secure Java NIO.2 APIs that perform proper path normalization. Development teams using Maven should update their project configuration to reference the secure dependency version:

<dependency>
    <groupId>com.github.junrar</groupId>
    <artifactId>junrar</artifactId>
    <version>7.6.1</version>
</dependency>

If upgrading the library is not immediately feasible, developers must implement manual input sanitization. This involves analyzing the filenames of archive entries before invoking the Junrar extraction methods. Applications should reject archives containing filenames that include relative path segments like .. or those containing backslash characters that function as path separators on specific operating systems.

Security teams can monitor for exploitation attempts by inspecting application logs for anomalous directory creation patterns or directory-related exceptions. Additionally, file integrity monitoring solutions can be configured to detect unauthorized directory creation events occurring outside the expected sandbox directories. Regular scanning of software bills of materials will identify older versions of the Junrar library and flag them for remediation.