Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Junrar's RAR virtual machine can be forced into a deterministic infinite loop while extracting a crafted RAR4 archive. The RarVM.ExecuteCode loop is intended to be bounded by maxOpCount, but jump instructions can bypass this limit when setIP() is called with a target instruction pointer greater than or equal to codeSize. An unauthenticated attacker who can provide a RAR archive to an application using Junrar.extract() can cause the extraction thread to spin forever, consuming CPU and blocking the process. The issue is a denial of service vulnerability, not remote code execution. Details The root cause is in src/main/java/com/github/junrar/unpack/vm/RarVM.java. setIP() returns early when the target IP is outside the prepared VM program: When ip = codeSize, this branch: - does not update IP; - does not decrement maxOpCount; - returns true, so callers treat it as success. The VMJMP handler and the other jump-like handlers discard the return value of setIP() and immediately…
Recommended action: Upgrade to 7.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
LocalFolderExtractor validates only the final canonical file path before extraction. However, makeFile() creates intermediate directories one path segment at a time without checking whether each created directory remains inside the destination folder. A malicious RAR entry can make the final file path resolve inside the extraction destination, while causing intermediate mkdir() calls to create attacker-chosen directories outside the extraction root. This is an extraction root escape via unchecked intermediate directory creation. The default impact is directory creation outside the intended destination, not unconditional arbitrary file content write. Affected Code - src/main/java/com/github/junrar/LocalFolderExtractor.java - createFile() checks only the final canonical path. - makeFile() calls dir.mkdir() for each intermediate segment without containment checks. Relevant code flow: Impact An attacker who can supply a malicious RAR archive can create directories outside the…
Recommended action: Upgrade to 7.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A path traversal vulnerability in LocalFolderExtractor allows an attacker to write arbitrary files with attacker-controlled content into sibling directories when a crafted RAR archive is extracted. Example Given an extraction directory set to /tmp/extract, a crafted archive with an entry with the filename as ../extractevil/file.txt would be actually extracted to /tmp/extractevil/file.txt. Details The createDirectory() and createFile() methods inLocalFolderExtractor validate extraction paths using a string prefix.
Recommended action: Upgrade to 7.5.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 validates extraction paths using getCanonicalPath().startsWith() to ensure files stay within the destination directory: 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: This converts the literal backslashes into real directory traversal:…
Recommended action: Upgrade to 7.5.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A carefully crafted RAR archive can trigger an infinite loop while extracting said archive. The impact depends solely on how the application uses the library, and whether files can be provided by malignant users. Patches The problem is partially patched in 7.4.1 Workarounds None References https://github.com/junrar/junrar/issues/73 https://github.com/junrar/junrar/issues/81
Recommended action: Upgrade to 7.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Archive.java in Junrar before 1.0.1, as used in Apache Tika and other products, is affected by a denial of service vulnerability due to an infinite loop when handling corrupt RAR files.
Recommended action: Upgrade to 1.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.