GitHub Security Advisory: GHSA-j273-m5qq-6825
Package: com.github.junrar:junrar (MAVEN)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 7.5.8
Patched in: 7.5.8

Summary: Junrar has an arbitrary file write due to backslash Path Traversal bypass in LocalFolderExtractor on Linux/Unix

Details:
### Summary

A backslash path traversal vulnerability in `LocalFolderExtractor` allows an attacker to write arbitrary files with attacker-controlled content anywhere on the filesystem when a crafted RAR archive is extracted on Linux/Unix. This can often lead to remote code execution (e.g., overwriting shell profiles, source code, cron jobs, etc).

### Details

The `createFile()` method in [`LocalFolderExtractor.java`](https://github.com/junrar/junrar/blob/master/src/main/java/com/github/junrar/LocalFolderExtractor.java) validates extraction paths using `getCanonicalPath().startsWith()` to ensure files stay within the destination directory:

```java
File f = new File(destination, name);
String dirCanonPath = f.getCanonicalPath();
if (!dirCanonPath.startsWith(destination.getCanonicalPath())) {
    throw new IllegalStateException("Rar contains file with invalid path: '" + dirCanonPath + "'");
}
```

On Linux/Unix, backslashes are literal filename characters, not path separators. A RAR entry named `..\..\tmp\evil.txt` is treated by `getCanonicalPath()` as a single literal filename containing backslash characters — no `..` resolution occurs, and the `startsWith` check passes.

However, `makeFile()` then splits the filename on backslashes and reconstructs the path using the platform's file separator:

```java
final String[] dirs = name.split("\\\\");
// dirs = ["..", "..", "tmp", "evil.txt"]
// ...
path = path + File.separator + dirs[i];  // File.separator is "/" on Linux
```

This converts the literal backslashes into real directory traversal: `../../tmp/evil.txt`. The `extract()` method then opens a `FileOutputStream` on this path and writes the RAR entry's content to it, achieving arbitrary file write outside the extraction directory.

On Windows this is not exploitable because backslashes are path separators, so `getCanonicalPath()` correctly resolves the `..` components and the `startsWith` check blocks the traversal.

**Affected versions:** Tested on 7.5.7 (latest). Likely affects all versions that include the `makeFile()` backslash-splitting logic in `LocalFolderExtractor`.

### PoC (Files Below)

**Prerequisites:** Linux/Unix system with Java 17+ and Maven installed.

1. Run `bash poc_setup.sh` which installs junrar 7.5.7 via Maven, creates a malicious RAR archive containing an entry with a backslash-traversal filename (`..\..\tmp\existing-file`), and creates `/tmp/existing-file` with the content "Existing File" to simulate a pre-existing file.
2. Run `mvn exec:java -Dexec.mainClass='com.test.BackslashTraversalPoC' -q`
3. Observe the output shows `/tmp/existing-file` was overwritten from "Existing File" to "Overwritten", confirming the file outside the extraction directory was written with attacker-controlled content.

The PoC uses `Junrar.extract()` — the standard public API for extracting RAR archives.

### Impact

Any application that extracts user-supplied RAR archives using junrar on Linux/Unix is vulnerable to arbitrary file write/overwri