CVE-2026-97370
7.5HighPublished 15 Oct 2026 · NVD status: Deferred · AI triage by gemini-3.8-flash
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
- Impact
- High impact on availability
- Weakness
- CWE-835
Impact
Remote, unauthenticated attackers can cause a permanent denial of service by exhausting worker CPU threads. An attacker only needs to submit a crafted RAR4 archive to any service parsing archives with Junrar.
Root cause
The RarVM JMP instruction handler fails to advance the instruction pointer or decrement the operation counter when jumping past the code boundary, creating an infinite loop.
Affected systems
Junrar versions prior to 7.6.1
CVSS v3.1 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Fix & remediation
Upgrade the com.github.junrar:junrar dependency to version 7.6.1. If patching immediately is impossible, reject or drop incoming RAR4 archives before worker extraction.
$ ./gradlew dependencyUpdates | grep junrar || mvn versions:display-dependency-updates | grep junrarAI-suggested. Run it in staging first and check it against the vendor advisory. Why?
NVD description
Junrar is an open source Java RAR archive library. Prior to 7.6.1, RarVM.ExecuteCode in src/main/java/com/github/junrar/unpack/vm/RarVM.java can repeatedly execute a VM_JMP instruction whose target is greater than or equal to the prepared program's codeSize. The setIP() function returns success without changing the instruction pointer or decrementing maxOpCount, and the jump handler continues before loop-end accounting, leaving both values unchanged. A crafted RAR4 archive can therefore keep an extraction thread in an infinite CPU loop and exhaust archive-processing worker capacity. The RAR virtual machine does not expose native process execution, so the supported impact is availability loss rather than code execution. This issue is fixed in version 7.6.1.