Junrar Path Traversal: Arbitrary File Write via Backslash Confusion

Junrar is a widely used open-source Java library for extracting RAR archives. A security vulnerability identified as CVE-2026-28208 affects versions prior to 7.5.8, specifically when running on non-Windows operating systems (Linux/Unix). The vulnerability allows for directory traversal, enabling the extraction of files to locations outside the intended destination directory.

The issue falls under CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). Unlike typical path traversal bugs where the application fails to sanitize ../ sequences, this vulnerability exploits a platform-specific interpretation of the backslash (\) character. While Windows treats backslashes as directory separators, POSIX systems treat them as valid literal characters within a filename. This discrepancy leads to a bypass of the library's security controls, resulting in arbitrary file write capabilities.

The vulnerability is rooted in a logical inconsistency between the validation phase and the file creation phase within LocalFolderExtractor.java. The library attempts to prevent path traversal by resolving the canonical path of the extraction destination and ensuring it starts with the intended target directory.

However, on Linux and Unix systems, the java.io.File API interprets backslashes (\) as literal characters, not directory separators. When the validation logic processes a malicious entry name like ..\..\etc\passwd, File.getCanonicalPath() treats the entire string as a single filename located inside the destination directory. Since no directory traversal is detected by the OS at this stage, the path validation check passes successfully.

Crucially, after validation, the library performs a manual path reconstruction to support Windows-style archives. The makeFile method explicitly splits the entry name using backslashes (name.split("\\\\")) and reassembles it using the system's native file separator (which is / on Linux). This transformation effectively converts the literal backslashes—which passed validation—into functional directory separators, executing the directory traversal that the validation step failed to detect.

The vulnerability existed in how the LocalFolderExtractor class handled file paths. Below is the logic flow demonstrating the flaw and the subsequent fix.

Vulnerable Logic (Simplified):

The code first validates the path using getCanonicalPath. On Linux, dest/..\file resolves to exactly that path, satisfying the startsWith check. Later, the file is created by splitting on backslashes.

// Vulnerable implementation in LocalFolderExtractor.java
private File createFile(FileHeader fh, File destination) {
    // 1. Validation: On Linux, backslashes are NOT separators.
    // A path like "..\\..\\evil.sh" is seen as a valid filename.
    File f = new File(destination, fh.getFileName());
    if (!f.getCanonicalPath().startsWith(destination.getCanonicalPath())) {
        throw new Exception("Malicious path");
    }
    return f;
}
 
// Later, in makeFile or similar logic:
// 2. Reconstruction: The filename is split by backslash and rejoined with '/'
// converting the "safe" filename into a traversal path.
String[] parts = fh.getFileName().split("\\\\");
File current = destination;
for (String part : parts) {
    current = new File(current, part);
}

Patched Logic:

The fix introduces input normalization before any validation occurs. The helper method invariantSeparatorsPathString replaces all backslashes with forward slashes. This ensures getCanonicalPath correctly identifies and resolves traversal attempts regardless of the OS.

// Fixed implementation in Commit 947ff1d
private File createFile(final FileHeader fh, final File destination) throws IOException {
    // FIX: Normalize backslashes to forward slashes BEFORE validation
    String name = invariantSeparatorsPathString(fh.getFileName());
    
    File f = new File(destination, name);
    // Now "../../evil.sh" is correctly resolved and rejected
    if (!f.getCanonicalPath().startsWith(destination.getCanonicalPath())) {
        throw new IllegalStateException("Rar contains file with invalid path");
    }
    return f;
}
 
static String invariantSeparatorsPathString(String path) {
    return path.replace("\\", "/");
}

To exploit this vulnerability, an attacker must craft a RAR archive containing a file entry with a specific naming convention and induce a victim to extract it on a vulnerable Linux/Unix system.

Step-by-Step Attack Vector:

1. Archive Creation: The attacker creates a RAR archive. Using a hex editor or a custom script (e.g., Python), they modify a file header to include backslash sequences targeting a sensitive location. For example: ..\..\..\..\home\victim\.bashrc.
2. Delivery: The archive is delivered to the target application, which uses Junrar for extraction.
3. Validation Bypass: The application calls createFile. The Linux filesystem interprets the filename as a literal string. The canonical path remains within the extraction root, bypassing the security check.
4. Path Transformation: The library's extraction logic splits the filename by \ and rejoins it with /. The path becomes ../../../../home/victim/.bashrc.
5. Execution: The content is written to the target file. If the attacker overwrites a shell profile, cron job, or authorized keys file, they achieve Remote Code Execution (RCE) the next time that resource is used.

The impact of CVE-2026-28208 is rated as Medium (CVSS 5.9), primarily due to the complexity requirement (AC:H) that the application must process a malicious file on a specific OS type (non-Windows). However, the practical impact is severe if these conditions are met.

Consequences:

• Arbitrary File Write: Attackers can write files anywhere the application process has write permissions. This is not limited to the extraction directory.
• Remote Code Execution (RCE): By overwriting configuration files (e.g., /etc/cron.d/*, ~/.ssh/authorized_keys, or web server scripts), an attacker can execute arbitrary commands on the host system.
• Denial of Service: Critical system files could be corrupted or overwritten, rendering the application or the host system unstable.

The vulnerability does not affect Windows deployments because java.io.File on Windows correctly interprets backslashes as separators, allowing the canonical path check to function as intended.