Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessUpload crafted RAR4 archive to processing service
-
Deliveryjunrar invokes RarVM.ExecuteCode
-
ExploitVM_JMP target ≥ codeSize, setIP returns without advancing IP or decrementing maxOpCount
-
ExecutionExtraction thread spins in infinite CPU loop
-
ImpactWorker pool exhausted, denial of service
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Loop termination conditions
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires an application using junrar prior to 7.6.1 to parse an attacker-supplied RAR4 archive, where the archive embeds a RAR virtual-machine program containing a VM_JMP instruction whose target is greater than or equal to the prepared program's codeSize. The RAR4 VM code path (not RAR5) must be reachable, meaning the host application must feed untrusted archives through junrar's extraction/VM processing. No authentication or user interaction is required per CVSS (PR:N/UI:N) when the archive is processed server-side automatically; the practical limiting factor is that the target must actually process untrusted RAR4 content through junrar, and impact is confined to CPU/thread exhaustion (availability) with no data exposure or code execution. |
| Impact | This is a genuine but bounded availability risk, not a critical priority. The CVSS 7.5 is driven entirely by the availability impact (A:H) with a clean network-reachable, unauthenticated, low-complexity vector (AV:N/AC:L/PR:N/UI:N) and no confidentiality or integrity impact (C:N/I:N) - consistent with CWE-835 (infinite loop). No EPSS score, KEV listing, or POC was provided in the input, so exploitation likelihood cannot be quantified from the data; based on available signals this is 'no public exploit identified at time of analysis.' The one clear conflict is the input 'RCE' tag, which directly contradicts the vendor description: the advisory explicitly states the RAR VM does not expose native process execution and that impact is availability loss only - treat the RCE tag as erroneous. Net: a real, easy-to-trigger DoS against services that process untrusted RAR archives with junrar, but it does not enable code execution and lacks confirmed in-the-wild exploitation, so it warrants patching rather than emergency response. |
| Exploit ScenarioDerived | An application (e.g., a file-processing or antivirus/indexing service such as those embedding junrar via Apache Tika) accepts user-uploaded RAR archives and extracts them with junrar prior to 7.6.1. An attacker submits a crafted RAR4 archive whose embedded RAR VM program contains a VM_JMP instruction targeting an offset at or beyond codeSize; the extraction worker thread spins indefinitely at 100% CPU. No public exploit code was identified in the provided data, but the condition is trivially constructible given the described flaw. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 15, 2026
Denial of service in Junrar before 7.6.1 allows unauthenticated remote attackers to exhaust CPU and archive-processing worker capacity by supplying a crafted RAR4 archive. The archive drives the built-in RAR virtual machine into an infinite loop via a VM_JMP instruction targeting an address at or beyond the prepared program's codeSize; because the VM cannot execute native code, the supported impact is availability loss rather than code execution. No public exploit code or confirmed active exploitation has been identified, and the flaw is fixed in version 7.6.1.
RemediationAI
Vendor-released patch: Junrar 7.6.1 (https://github.com/junrar/junrar/releases/tag/v7.6.1), as described in the advisory https://github.com/junrar/junrar/security/advisories/GHSA-h9h9-2rmf-rvhp and implemented in commit https://github.com/junrar/junrar/commit/687a09c42f46066447faa9179ee11314ad6d9afb; upgrade to 7.6.1 or later. If immediate upgrade is not possible, impose a hard per-archive extraction timeout and cap the concurrent extraction worker pool so one malicious archive cannot consume all worker capacity-this reduces throughput and may terminate legitimate long-running extractions. Also consider isolating archive processing in a separate low-privilege process or container with CPU quotas, and restrict untrusted RAR4 uploads to authenticated or trusted users; these controls add operational complexity and may reject benign archives. Because the CVSS vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, prioritize patching any Internet-facing service that automatically processes uploaded RAR4 archives.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in maven, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Junrar is an open source Java library for reading RAR archives; the affected component is the RarVM class in src/main/java/com/github/junrar/unpack/vm/RarVM.java, used when processing RAR4 archives that contain virtual-machine filters. The root cause is CWE-835 (Infinite Loop): in RarVM.ExecuteCode, a VM_JMP instruction whose target is greater than or equal to the prepared program's codeSize causes setIP() to return true without changing the instruction pointer or decrementing maxOpCount, and the jump handler continues before the loop-end accounting that would otherwise exhaust the operation budget. Consequently the extraction thread spins indefinitely, consuming CPU and holding a worker slot. The RAR VM is not designed to expose native process execution, so the tag 'RCE' in intelligence feeds is not supported by the code path; the confirmed impact is availability loss. The CPE cpe:2.3:a:junrar:junrar:*:*:*:*:*:*:*:* reflects the affected Junrar package, with the vendor advisory and fix commit 687a09c42f46066447faa9179ee11314ad6d9afb pointing to version 7.6.1 as the remediation boundary.
Know when Junrar gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Crafted archive is typically supplied over the network to an automated extraction service with no auth or interaction (AV:N/AC:L/PR:N/UI:N); only availability is affected (A:H, C/I:N).
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
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.
Blast Radius
ecosystem impact- 3 maven packages depend on com.github.junrar:junrar (1 direct, 2 indirect)
Ecosystem-wide dependent count for version 7.6.1.
Technical POC Analysis
Bug class: CWE-835, Loop with Unreachable Exit Condition ("Infinite Loop") (the advisory body itself lists "No CWEs"; CWE-835 is the classification supplied with the CVE metadata).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
A high-severity flaw in Junrar, the widely embedded Java library used to extract RAR archives, allows a specially crafted RAR4 file to lock archive-processing threads in a non-terminating loop, exhausting CPU and worker capacity on any service that accepts or processes RAR uploads. Impact is limited to availability - no code execution or data exposure is possible - but affected services can be degraded or taken offline remotely and repeatedly. Leadership should care because customer-facing upload, ingestion, and malware-scanning pipelines that depend on this library may become unavailable, and remediation requires a coordinated dependency upgrade across every Java application that bundles it.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Junrar versions prior to 7.5.8 contain a path traversal vulnerability in LocalFolderExtractor that allows attackers to w
Path traversal in junrar (the open source Java RAR archive library) prior to version 7.6.1 lets an attacker-supplied RAR
Path traversal in Junrar library versions prior to 7.5.10 allows remote attackers to write arbitrary files into sibling
Archive.java in Junrar before 1.0.1, as used in Apache Tika and other products, is affected by a denial of service vulne
EUVD-2026-102251
GHSA-h9h9-2rmf-rvhp
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB