Junrar CVE-2026-41245

The vulnerability requires the following specific conditions: (1) A Java application must use Junrar library version prior to 7.5.10, (2) the application must extract RAR archives to the filesystem using the LocalFolderExtractor component (the standard extraction method), and (3) the attacker must be able to supply or control the RAR archive being extracted. The attacker does not need authentication or direct filesystem access - they only need to provide a crafted RAR file to the application (e.g., via file upload, email attachment, or compromised package repository). Exploitation does not require user interaction from the application operator, and does not require any special configuration of Junrar itself. The high complexity (AC:H) in CVSS likely reflects that successful exploitation requires precise knowledge of the target filesystem layout to traverse to an impactful sibling directory; however, in many deployments (e.g., where Junrar extracts to a predictable location), this knowledge is easily obtainable. No special platform, runtime version, or non-default configuration is required - any Java 8+ runtime executing Junrar 7.5.9 or earlier is vulnerable if it processes untrusted RAR files.

This vulnerability presents moderate-to-significant real-world risk despite a CVSS score of 5.9 (medium). The CVSS vector AV:N/AC:H/PR:N/UI:N indicates network-reachable exploitation with high complexity but no authentication or user interaction required - the AC:H factor is likely due to the need for a specially-crafted RAR archive and the specific filesystem layout required for exploitation impact. The vulnerability is NOT confirmed in active exploitation per available data (no KEV status provided, no public exploit code referenced), but the straightforward nature of path traversal flaws and public disclosure via GitHub suggest PoC development is likely. Real-world impact depends heavily on deployment context: if Junrar is used in a service that processes user-uploaded RAR files, or in build pipelines extracting dependencies, the risk is significant. If usage is limited to extracting known-good archives, risk is lower. The inability to impact confidentiality or availability (C:N, A:N per CVSS) limits scope compared to RCE, but arbitrary file write enables downstream attacks: injecting malicious JAR files into classpath directories, overwriting configuration files, or replacing executable scripts. Organizations using Junrar should prioritize patching if they extract untrusted RAR files; those extracting only internal/verified archives can defer. No conflict between CVSS and description.

An attacker crafts a malicious RAR archive containing an entry with a path like ../../../malicious.jar or ../config/override.properties. When a Java application using vulnerable Junrar extracts this archive to a directory like /app/uploads/, the path traversal allows the attacker to write files to /app/config/ or other sibling/parent locations. If the application's classpath includes these directories, the attacker can inject a malicious JAR to achieve code execution on the next application restart or class loading event. Alternatively, overwriting application configuration files allows the attacker to alter behavior without code execution.