CVE-2026-97370 junrar CVE debrief

Who should care

Defenders responsible for maintaining and securing applications that use Junrar for RAR archive extraction should assess exposure and prioritize verification and remediation. They should review the supplied official advisory or CVE record to validate affected scope, severity, and vendor guidance. Additionally, defenders should plan vendor-supported updates or mitigations through normal change control where exposure is confirmed and review compensating

Why it matters

Defenders should care about CVE-2026-97370 because it allows an unauthenticated attacker to cause a denial-of-service vulnerability in Junrar, potentially leading to increased resource utilization and blocking of extraction threads.

• Potential denial-of-service attacks through CPU consumption
• Blocking of extraction threads
• Increased resource utilization

Technical summary

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, allowing an attacker to bypass the `maxOpCount` limit and cause an infinite loop. This occurs because `setIP()` does not update `IP` or decrement `maxOpCount` when the target IP is outside the prepared VM program. The `VM_JMP` handler and other jump-like handlers discard the return value of `setIP()` and immediately continue execution, which can lead to an infinite loop.

Defensive priority

Defenders should prioritize verifying and updating Junrar to version 7.6.1 or later to prevent potential denial-of-service attacks.

Recommended defensive actions

• Verify Junrar version and update to 7.6.1 or later
• Review and restrict RAR archive extraction processes
• Monitor system resources for potential denial-of-service attacks
• Confirm whether affected product deployments exist in managed environments and assign an owner for follow-up
• Review the supplied official advisory or CVE record to validate affected scope, severity, and vendor guidance
• Plan vendor-supported updates or mitigations through normal change control where exposure is confirmed
• technicalSummary

Evidence notes

The issue is caused by a flaw in the `setIP()` method of the `RarVM` class, which allows an attacker to bypass the `maxOpCount` limit and cause an infinite loop. This method does not update `IP` or decrement `maxOpCount` when the target IP is outside the prepared VM program. The vulnerability can be triggered by providing a crafted RAR archive to an application using `Junrar.extract()`, potentially leading to increased resource utilization and blocking of extraction threads.

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.