Junrar (Java), Path Traversal (Zip-Slip), CVE-2026-28208 (Moderate)

Listen to this Post

How CVE-2026-28208 Works

The vulnerability exists in the `LocalFolderExtractor` component of Junrar, a Java RAR extraction library. It stems from a logical inconsistency between how path validation and file creation handle the backslash (\) character on Linux/Unix systems, allowing a Zip-Slip style attack.
1. Path Validation Bypass: The `createFile()` method in `LocalFolderExtractor.java` attempts to prevent path traversal by checking that the canonical path of a new file starts with the canonical path of the extraction directory (destination.getCanonicalPath()). On Linux/Unix, a backslash is treated as a legal character in a filename, not a path separator.
2. The Bypass: When a crafted RAR archive contains a file entry with a name like ..\..\tmp\evil.txt, `getCanonicalPath()` sees this as a single literal filename containing backslashes, not a path with `..` components. Consequently, the `startsWith` validation check passes.
3. Exploitation via Manual Splitting: After validation, the `makeFile()` method in the same class splits the filename using String[] dirs = name.split("\\\\"). This converts `..\..\tmp\evil.txt` into an array of directory elements ({"..", "..", "tmp", "evil.txt"}).
4. Path Reconstruction: `makeFile()` then reconstructs the path using the platform’s file separator (File.separator), which on Linux/Unix is /. This effectively transforms the literal filename into ../../tmp/evil.txt.
5. Arbitrary File Write: The `extract()` method proceeds to open a `FileOutputStream` on this path and writes the archive entry’s content to it, overwriting any file on the system that the Java process has permissions to modify. This can lead to Remote Code Execution by, for example, overwriting SSH keys, cron jobs, or system binaries.

DailyCVE Form

Platform: Junrar
Version: <7.5.8
Vulnerability: Path Traversal
Severity: Moderate
Date: 2026-02-26

Prediction: Patch already (7.5.8)

What Undercode Say:

The vulnerability is a classic example of a path traversal flaw, but with an interesting twist. Developers often rely on `getCanonicalPath().startsWith()` as a robust validation mechanism, assuming it will handle all cases. This logic is correct on Windows, where the backslash is a path separator. However, on Linux/Unix, this creates a blind spot.

Analytics from the Undercode team:

  • The `split(“\\\\”)` logic is the core problem. It assumes that a backslash always indicates a directory separator, which is false on Linux.
  • This vulnerability was fixed by replacing the manual split logic with `new File(destination, name).getCanonicalPath()` after the initial validation, ensuring that the final path is properly resolved. It’s also recommended to deny any entry name containing backslashes on Unix systems.
  • To detect this issue, static analysis tools can flag calls to `File` constructors where the path is derived from user input and then split on backslashes.

Bash Commands and Codes:

Test if a system is vulnerable (Example using a malicious RAR)
First, create a benign file to overwrite
echo "Existing File" > /tmp/existing-file
Assuming a malicious.rar created with a file entry named '....\tmp\existing-file'
The following Java code (if using vulnerable Junrar) would overwrite /tmp/existing-file
cat > VulnerableExtractor.java << 'EOF'
import com.github.junrar.Junrar;
import java.io.File;
public class VulnerableExtractor {
public static void main(String[] args) {
File rarFile = new File("malicious.rar");
File destDir = new File("/tmp/extract");
Junrar.extract(rarFile, destDir); // Vulnerable call
System.out.println("Extraction attempted.");
}
}
EOF
To compile and run, ensure junrar < 7.5.8 is in the classpath.

Exploit:

An attacker crafts a RAR archive containing a file entry with a specially crafted name, such as ..\..\path\to\target.file. When this archive is extracted by a vulnerable application on a Linux/Unix system, the application will write the contents of that archive entry to a location outside the intended extraction directory. This can be used to overwrite critical system files, user configuration files, or inject malicious code into startup scripts.

Protection from this CVE

The primary mitigation is to upgrade to Junrar version 7.5.8 or later. If an immediate upgrade is impossible, the following workarounds can be applied:
1. Validate Entry Names: Before extraction, scan all entry names in the RAR archive and reject any that contain backslash (\) characters.
2. Sanitize Paths: After validating the canonical path, ensure the final file path is normalized and still within the intended extraction directory.
3. Restrict File System Permissions: Run the extraction process with the least privileges necessary, limiting the scope of potential damage.

Impact

  • Arbitrary File Write: An attacker can write files with arbitrary content anywhere on the file system that the application has write access to.
  • Remote Code Execution (RCE): By overwriting critical system files (e.g., .bashrc, .ssh/authorized_keys, /etc/crontab, web application source code), an attacker can often escalate the file write into full remote code execution.
  • Confidentiality: The vulnerability does not directly leak information, but it can be a stepping stone for further attacks.
  • Availability: Overwriting system files can lead to denial of service.

🎯Let’s Practice Exploiting & Learn Patching For Free:

Sources:

Reported By: github.com
Extra Source Hub:
Undercode

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow DailyCVE & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin Featured Image

Scroll to Top