CVE-2022-23596

7.5 HIGH

📋 TL;DR

CVE-2022-23596 is a denial-of-service vulnerability in the Junrar Java RAR archive library where a malicious RAR file can trigger an infinite loop during extraction. This affects any Java application that uses vulnerable versions of Junrar to process user-supplied RAR archives. The impact ranges from application unresponsiveness to resource exhaustion depending on how the library is integrated.

💻 Affected Systems

Products:
  • Junrar (Java RAR archive library)
Versions: All versions before 7.4.1
Operating Systems: All operating systems running Java applications using Junrar
Default Config Vulnerable: ⚠️ Yes
Notes: Only vulnerable when processing RAR archives. Applications must use the affected extraction functionality.

📦 What is this software?

⚠️ Risk & Real-World Impact

🔴

Worst Case

Complete denial of service through resource exhaustion (CPU/memory), potentially crashing the application or server hosting the vulnerable Junrar library.

🟠

Likely Case

Application becomes unresponsive when processing malicious RAR files, requiring restart and causing service disruption.

🟢

If Mitigated

Limited impact if application runs with resource limits, sandboxing, or only processes trusted archives.

🌐 Internet-Facing: HIGH if application accepts RAR files from untrusted users via web interfaces, APIs, or file uploads.
🏢 Internal Only: MEDIUM if only internal users can supply RAR files, but risk exists from insider threats or compromised accounts.

🎯 Exploit Status

Public PoC: ⚠️ Yes
Weaponized: LIKELY
Unauthenticated Exploit: ⚠️ Yes
Complexity: LOW

Proof-of-concept exists in GitHub issues. Creating malicious RAR files requires understanding of the infinite loop condition but is straightforward for attackers.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: 7.4.1

Vendor Advisory: https://github.com/junrar/junrar/security/advisories/GHSA-m6cj-93v6-cvr5

Restart Required: Yes

Instructions:

1. Identify applications using Junrar
2. Update Junrar dependency to version 7.4.1 or later in build configuration (Maven, Gradle, etc.)
3. Rebuild and redeploy affected applications
4. Restart services using the updated library

🔧 Temporary Workarounds

Input validation and filtering

all

Reject or sanitize RAR file inputs before processing with Junrar

Resource limiting

linux

Configure CPU/time limits on processes that extract RAR archives

On Linux: Use ulimit -t to set CPU time limits
In Java: Use -XX:ActiveProcessorCount or container resource limits

🧯 If You Can't Patch

  • Implement strict input validation to reject suspicious RAR files before Junrar processing
  • Run Junrar operations in isolated containers with strict resource limits and monitoring

🔍 How to Verify

Check if Vulnerable:

Check build configuration files (pom.xml, build.gradle) for Junrar dependency version below 7.4.1

Check Version:

For Maven: mvn dependency:tree | grep junrar; For Gradle: gradle dependencies | grep junrar

Verify Fix Applied:

Confirm Junrar version 7.4.1 or later appears in dependency tree and application manifest

📡 Detection & Monitoring

Log Indicators:

  • Repeated extraction attempts failing with timeouts
  • High CPU usage spikes from Java processes handling archives
  • Application restarts following file uploads

Network Indicators:

  • Multiple RAR file uploads to vulnerable endpoints
  • Unusual archive upload patterns

SIEM Query:

source="application.logs" AND ("extraction timeout" OR "archive processing" OR "RAR") AND (cpu_usage>90 OR process_duration>300s)

🔗 References

📤 Share & Export