CVE-2026-97370: Junrar Java RAR Library DOS Vulnerability

CVE-2026-97370 Overview

CVE-2026-97370 is an infinite loop vulnerability [CWE-835] in Junrar, an open source Java library for extracting RAR archives. Versions prior to 7.6.1 mishandle the VM_JMP instruction in the embedded RAR virtual machine. A crafted RAR4 archive can force an extraction worker into an unbounded CPU loop, exhausting archive-processing capacity on the host.

The flaw affects availability only. The RAR virtual machine implemented by Junrar does not provide native process execution, so attackers cannot achieve code execution through this issue.

Critical Impact
A single malicious RAR4 archive can lock an extraction thread in an infinite loop, exhausting worker pool capacity and causing denial of service across applications that use Junrar for untrusted archive processing.

Affected Products

Junrar library versions prior to 7.6.1
Java applications embedding Junrar for RAR archive extraction
Server-side services that accept and extract user-supplied RAR archives

Discovery Timeline

2026-10-15 - CVE-2026-97370 published to NVD
2026-10-16 - Last updated in NVD database

Technical Details for CVE-2026-97370

Vulnerability Analysis

The vulnerability lives in RarVM.ExecuteCode in src/main/java/com/github/junrar/unpack/vm/RarVM.java. The RAR virtual machine executes filter bytecode embedded in RAR4 archives to transform compressed data. Each virtual instruction decrements a maxOpCount budget intended to prevent runaway execution.

When the VM dispatches a VM_JMP instruction, it calls setIP() to update the instruction pointer. If the jump target is greater than or equal to the prepared program's codeSize, setIP() returns success without updating the instruction pointer and without decrementing maxOpCount. The jump handler then continues to the next loop iteration before the end-of-loop accounting runs, so neither the instruction pointer nor the operation counter changes.

The VM therefore re-executes the same out-of-range VM_JMP instruction indefinitely. The thread consumes a full CPU core and never returns to its caller, blocking the extraction worker that invoked it.

Root Cause

The root cause is missing validation and missing budget accounting in the jump path. setIP() silently rejects an invalid target instead of signaling failure, and the jump handler bypasses the counter decrement that normally bounds execution. Together these create an unbounded loop reachable from attacker-controlled archive data.

Attack Vector

An attacker crafts a RAR4 archive containing filter bytecode whose VM_JMP target exceeds codeSize. When a victim application extracts the archive with a vulnerable version of Junrar, the extraction thread enters an infinite loop. Repeated submissions can exhaust an application's worker pool and prevent legitimate archive processing.

java

// Patch excerpt from LocalFolderExtractor.java (v7.6.1)
    private File makeFile(final Path file) throws IOException {
-        if(file.getParent() == null) return null;
+        if (file.getParent() == null) return null;
        Files.createDirectories(file.getParent());
        return file.toFile();
    }

Source: GitHub Commit 687a09c. The release ships broader RarVM guards that validate VM_JMP targets and ensure maxOpCount is decremented on every dispatch.

Detection Methods for CVE-2026-97370

Indicators of Compromise

Java worker threads sustaining 100% CPU utilization while executing frames inside com.github.junrar.unpack.vm.RarVM.ExecuteCode.
Archive-processing queues growing without completion events, correlated with recent uploads of .rar files.
Thread dumps showing multiple extraction workers blocked in the same RarVM call stack for extended periods.

Detection Strategies

Software composition analysis against application dependencies to identify Junrar versions earlier than 7.6.1.
Runtime watchdogs that cap wall-clock time for individual archive extractions and record offending inputs.
JVM profiling or flight recorder sampling to flag threads spending disproportionate CPU time in RarVM.ExecuteCode.

Monitoring Recommendations

Alert on sustained high CPU in services that accept user-supplied archives, especially when correlated with upload events.
Track extraction latency and timeout counters per request to catch pool exhaustion early.
Log archive hashes and submitter identity so repeated malicious submissions can be attributed and blocked.

How to Mitigate CVE-2026-97370

Immediate Actions Required

Upgrade Junrar to version 7.6.1 or later in all applications that process RAR archives.
Inventory internal and third-party Java services for transitive dependencies on vulnerable Junrar versions.
Enforce per-extraction CPU and wall-clock timeouts so a single archive cannot monopolize a worker thread.

Patch Information

The issue is fixed in Junrar 7.6.1. See the GitHub Security Advisory GHSA-h9h9-2rmf-rvhp and GitHub Release v7.6.1 for the official notes. The underlying code change is documented in GitHub Commit 687a09c.

Workarounds

Disable RAR4 archive support in exposed services until the Junrar upgrade can be deployed.
Run archive extraction in isolated worker processes with strict CPU and memory limits to contain runaway threads.
Reject archives from untrusted sources or require authenticated submissions to reduce exposure to crafted inputs.

bash

# Example Maven dependency pin to the fixed version
# pom.xml
# <dependency>
#   <groupId>com.github.junrar</groupId>
#   <artifactId>junrar</artifactId>
#   <version>7.6.1</version>
# </dependency>
mvn dependency:tree | grep junrar