CVE-2022-23596
📋 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
- Junrar (Java RAR archive library)
📦 What is this software?
Junrar by Junrar Project
⚠️ 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.
🎯 Exploit Status
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
allReject or sanitize RAR file inputs before processing with Junrar
Resource limiting
linuxConfigure 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
- https://github.com/junrar/junrar/commit/7b16b3d90b91445fd6af0adfed22c07413d4fab7
- https://github.com/junrar/junrar/issues/73
- https://github.com/junrar/junrar/security/advisories/GHSA-m6cj-93v6-cvr5
- https://github.com/junrar/junrar/commit/7b16b3d90b91445fd6af0adfed22c07413d4fab7
- https://github.com/junrar/junrar/issues/73
- https://github.com/junrar/junrar/security/advisories/GHSA-m6cj-93v6-cvr5