Junrar RARVM Infinite Loop Denial of Service
An infinite loop vulnerability in the Junrar Java library, identified as CVE-2026-97370, allows unauthenticated attackers to cause CPU exhaustion via crafted RAR4 archives.
CVE search metadata
CVE search record: CVE-2026-97370. Severity: high. CVSS: 7.5. KEV: no. Product: junrar (<= 7.6.0). Brief: Junrar RARVM Infinite Loop Denial of Service. Brief link: https://feed.craftedsignal.io/briefs/2026-10-junrar-dos/
The Junrar Java library is susceptible to a denial-of-service (DoS) condition due to a logic flaw in the RAR virtual machine (RarVM). When processing a specially crafted RAR4 archive, the RarVM.ExecuteCode routine can be forced into an infinite loop. This occurs because the VM_JMP instruction handler improperly validates jump targets. When a jump target is equal to or greater than the defined codeSize, the setIP() function returns success without updating the instruction pointer (IP) or decrementing the maxOpCount safety counter.
Because the main VM loop continues immediately after the jump without updating these values, the same VM_JMP instruction is repeatedly executed. An attacker can exploit this by providing malicious archives to applications using Junrar.extract(), leading to permanent hang of extraction worker threads and resource exhaustion. This flaw, tracked as CVE-2026-97370, affects all versions of junrar up to and including 7.6.0. The vulnerability is restricted to availability impact and does not grant code execution due to Java's built-in memory protection.
Attack Chain
- Attacker crafts a malicious RAR4 archive containing a VM program with a
VM_JMPinstruction. - The instruction is configured with a target address that is greater than or equal to the archive's
codeSize. - The victim application invokes
Junrar.extract()on the uploaded or retrieved malicious RAR archive. - The
RarVMcomponent encounters the craftedVM_JMPinstruction during the extraction routine. - The
setIP()function validates the target address, returnstrue, but fails to update theIPvariable. - The main VM loop incorrectly ignores the
setIP()result and executes acontinuestatement, skipping themaxOpCountdecrement. - The VM loop re-executes the same
VM_JMPinstruction indefinitely. - The extraction thread consumes 100% CPU, leading to service degradation or process exhaustion.
Impact
Successful exploitation results in a persistent denial-of-service condition for applications relying on the junrar library. In multi-tenant environments or services that process file uploads, this vulnerability can be leveraged to exhaust worker thread pools, preventing the processing of legitimate files. No code execution is documented, but the inability to terminate the extraction loop may require a manual process restart to restore service functionality.
Recommendation
- Upgrade the
junrarlibrary to a version greater than 7.6.0 as soon as a patch is available. - Implement strict size and complexity limits on files processed by archival libraries to mitigate potential DoS vectors.
- Monitor application server thread health and resource utilization for extraction tasks.
- If updating is not immediately possible, implement a watchdog timer or thread timeout for archive extraction routines to force-terminate hung processes.
Immediate actions
Upgrade junrar library to version > 7.6.0
Mitigations
Implement thread-level timeouts for archive extraction routines
CVE-2026-97370