Summary
Junrar: RarVM VM_JMP maxOpCount bypass causes infinite CPU loop during RAR4 extraction
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:
private boolean setIP(int ip) {
if ((ip) >= codeSize) {
return (true);
}
if (--maxOpCount <= 0) {
return (false);
}
IP = ip;
return true;
}
When ip >= codeSize, this branch:
- does not update
IP; - does not decrement
maxOpCount; - returns
true, so callers treat it as success.
The VM_JMP handler and the other jump-like handlers discard the return value of setIP() and immediately continue the main VM loop:
case VM_JMP:
setIP(getValue(false, mem, op1));
continue;
Because of the continue, execution also skips the loop-end accounting:
IP++;
--maxOpCount;
As a result, a VM program containing a single VM_JMP instruction can freeze both IP and maxOpCount:
IPpoints to theVM_JMPinstruction.- The jump target resolves to
codeSizeor larger. setIP()returns before modifyingIPor decrementingmaxOpCount.- The caller ignores the return value and continues.
- The same
VM_JMPinstruction is executed again forever.
Impact
This is a CPU denial of service vulnerability. Any application that uses junrar to extract untrusted RAR archives can have an extraction worker thread permanently blocked by a small crafted archive. In services that process uploads or attachments automatically, repeated submissions can exhaust worker capacity and degrade or stop archive-processing functionality.
The RAR VM does not provide native code execution, reflection, or process execution primitives, and Java array bounds checks prevent escaping the VM memory array. The expected security impact is availability only.
CVE-2026-97370 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (7.6.1); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-97370? CVE-2026-97370 is a high-severity security vulnerability in com.github.junrar:junrar (maven), affecting versions <= 7.6.0. It is fixed in 7.6.1.
- How severe is CVE-2026-97370? CVE-2026-97370 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of com.github.junrar:junrar are affected by CVE-2026-97370? com.github.junrar:junrar (maven) versions <= 7.6.0 is affected.
- Is there a fix for CVE-2026-97370? Yes. CVE-2026-97370 is fixed in 7.6.1. Upgrade to this version or later.
- Is CVE-2026-97370 exploitable, and should I be worried? Whether CVE-2026-97370 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-97370 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-97370? Upgrade
com.github.junrar:junrarto 7.6.1 or later.