CVE-2026-97370: 
Java vulnerability analysis and mitigation

CVE-2026-97370 is a denial-of-service vulnerability in Junrar, an open-source Java RAR archive library, caused by an infinite CPU loop triggered during RAR4 archive extraction. The flaw exists in RarVM.ExecuteCode within src/main/java/com/github/junrar/unpack/vm/RarVM.java, where a crafted VM_JMP instruction can bypass the maxOpCount execution limit. All versions up to and including 7.6.0 are affected; the issue is fixed in version 7.6.1. It carries a CVSS v3.1 base score of 7.5 (High) (Github Advisory, Junrar Security Advisory). The vulnerability was originally published on July 21, 2026, and added to the GitHub Advisory Database on October 15, 2026.

The root cause is classified as CWE-835 (Loop with Unreachable Exit Condition / Infinite Loop). The setIP() function in RarVM.java is intended to bound VM execution via maxOpCount, but when the jump target IP is greater than or equal to codeSize, it returns true (success) without updating the instruction pointer or decrementing maxOpCount. The VM_JMP handler discards setIP()'s return value and uses continue, which also skips the loop-end accounting (IP++; --maxOpCount;). As a result, a crafted RAR4 archive containing a single VM_JMP instruction pointing to an out-of-bounds address causes the extraction thread to spin indefinitely. No authentication or user interaction is required — an attacker only needs to supply a malicious RAR4 archive to any application invoking Junrar.extract() (Github Advisory, Junrar Security Advisory).

Successful exploitation causes the extraction worker thread to permanently consume CPU, blocking archive-processing capacity. In services that automatically process uploaded or emailed attachments, repeated submission of crafted archives can exhaust all worker threads, degrading or completely halting archive-processing functionality. There is no confidentiality or integrity impact; the RAR VM does not expose native process execution, reflection, or process execution primitives, and Java array bounds checks prevent memory escape, so the impact is strictly availability loss (Github Advisory, Junrar Security Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (Github Advisory). The EPSS score is 0.0, indicating very low current probability of exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Despite the lack of active exploitation, the attack requires no privileges, no user interaction, and low complexity, making it straightforward to trigger against any exposed service that processes untrusted RAR archives.

1. Identify a target: Locate a service or application that uses Junrar (Maven artifact com.github.junrar:junrar version ≤ 7.6.0) to automatically extract RAR archives — such as file upload portals, email attachment processors, or document management systems.
2. Craft a malicious RAR4 archive: Construct a RAR4 archive containing a RAR VM program with a single VM_JMP instruction whose target address is set to a value greater than or equal to the program's codeSize. This causes setIP() to return true without advancing the instruction pointer or decrementing maxOpCount.
3. Submit the archive: Upload or send the crafted RAR4 file to the target service through any available input channel (file upload form, email attachment, API endpoint, etc.).
4. Trigger extraction: The application calls Junrar.extract() on the archive, causing the extraction thread to enter an infinite CPU loop executing the same VM_JMP instruction repeatedly.
5. Exhaust worker capacity: Repeat submissions with additional crafted archives to consume all available extraction worker threads, resulting in denial of service for legitimate archive-processing requests (Junrar Security Advisory, Github Advisory).

• Process: Java worker threads stuck at 100% CPU utilization for extended periods during RAR archive extraction; thread dumps showing threads permanently blocked inside RarVM.ExecuteCode or RarVM.setIP().
• Logs: Application logs showing RAR extraction operations that never complete or time out; repeated extraction requests for the same small archive file without completion.
• Network: Repeated submissions of small RAR4 archive files (potentially only a few bytes) from the same or rotating source IPs to file upload or attachment processing endpoints.
• File System: Presence of small, anomalous .rar files in upload or temporary directories that do not correspond to legitimate user activity.

The primary remediation is to upgrade Junrar to version 7.6.1 or later, which fixes the VM_JMP handling in RarVM.java (Junrar Release v7.6.1, Patch Commit). As interim workarounds, implement thread-level timeouts and resource limits on RAR extraction operations to automatically terminate stalled threads. Consider processing untrusted RAR archives in sandboxed or isolated environments with defined CPU and time constraints, and monitor for extraction threads consuming excessive CPU to enable automatic termination.

The vulnerability was discovered by researcher dds921 and sponsored by KeenSecurityLab, with the fix authored by the Junrar maintainer (gotson) (Junrar Security Advisory). No significant broader media coverage or notable community commentary beyond the official advisory has been identified at this time.