CVE-2026-4111

What it actually does

The flaw is a denial-of-service condition in libarchive's RAR5 decompression path, reached during archive_read_data() processing. A specially crafted but structurally valid RAR5 archive can cause the decompressor to stop making forward progress and enter an infinite loop. Because the archive can pass checksum and format validation, applications that rely on libarchive may accept the file as valid and only fail once decompression begins. The likely result is sustained CPU consumption by the process handling the archive, thread or worker exhaustion, delayed job queues, and loss of availability for services that automatically inspect, extract, index, scan, or ingest user-supplied archives.

Why it matters to the business

Organizations using applications or services that automatically process uploaded, emailed, downloaded, or synchronized archives may experience service degradation or outages if malicious RAR5 files are submitted repeatedly. Impact is availability-focused rather than data theft or data modification, but it can still disrupt customer-facing upload portals, malware-scanning pipelines, document-processing systems, backup/indexing workflows, CI/CD artifact processing, and email/security gateways. The CVSS score indicates high availability impact, while the currently low and flat EPSS score, absence from CISA KEV, and no known exploit maturity suggest lower immediate exploitation pressure; however, exposure remains important anywhere untrusted archives are processed automatically at scale.

How an attack unfolds

An attacker identifies an application, API, gateway, or background service that accepts or retrieves archive files and uses libarchive to process RAR5 content. The attacker prepares a malformed RAR5 archive that remains structurally valid enough to pass initial parsing and checksum validation but triggers the non-progress condition during archive_read_data(). The attacker then submits the archive through an upload form, email attachment, artifact repository, file-sharing workflow, support-ticket attachment, scanning pipeline, or any other automated ingestion path. When the affected service attempts to extract or inspect the archive, the decompression routine loops indefinitely and consumes CPU. Repeated submissions or concurrent processing can exhaust worker threads, increase queue depth, starve other workloads, and cause partial or complete service denial. There is no indication from the provided intelligence that this issue enables code execution, privilege escalation, data disclosure, ransomware deployment, or persistent compromise.

How to fix it

Upgrade libarchive and any products that bundle or statically link libarchive to a vendor-fixed version when available. Because no affected product list or fixed-version data was provided, teams should consult their operating system, container image, appliance, application, and package-manager advisories for libarchive fixes for CVE-2026-4111. Rebuild and redeploy applications that statically link libarchive; simply updating the system package may not protect embedded copies. Where immediate patching is not possible, reduce exposure by disabling RAR/RAR5 processing for untrusted inputs, enforcing strict archive-processing timeouts, applying CPU and memory limits to archive workers, isolating decompression in sandboxed worker processes, limiting concurrent archive jobs per user/source, enforcing maximum archive size and extraction limits, and queueing archive inspection in a way that prevents one stuck job from blocking all workers. Use process supervisors to terminate long-running extraction tasks and retry safely only after quarantining the triggering file.

How to confirm the fix worked

Confirm exposure by inventorying systems, containers, appliances, and applications that include libarchive or use libraries/tools backed by libarchive for archive extraction. Check package versions through OS package managers and software composition analysis, and separately identify statically linked or vendored libarchive copies. Validate remediation by confirming the installed or embedded libarchive build includes the vendor fix for this issue, then restart dependent services and redeploy rebuilt containers or binaries. In a controlled non-production environment, test archive-processing safeguards by submitting benign long-running or malformed archive test cases and verifying that worker timeouts, CPU limits, quarantine behavior, and queue isolation operate as expected. For production validation, monitor that archive-processing workers no longer show sustained high CPU on RAR5 inputs and that no recurring backlog or stuck jobs appear after patching.

Typical attack path

1. Find an externally reachable or indirectly reachable workflow that accepts archive files or automatically processes files from untrusted sources.
2. Confirm or infer that the workflow supports RAR/RAR5 extraction, content inspection, indexing, antivirus scanning, or metadata parsing through libarchive or software that embeds libarchive.
3. Create or obtain a specially crafted RAR5 archive that passes basic archive validation but triggers the infinite-loop behavior during decompression.
4. Submit the archive through an upload endpoint, email attachment, API, file synchronization path, artifact ingestion workflow, or scanning queue.
5. Wait for the target service to process the archive with the vulnerable libarchive RAR5 archive_read_data() path.
6. Cause sustained CPU consumption in the worker process or service handling the file.
7. Repeat or parallelize submissions to exhaust processing capacity, increase backlog, and degrade or deny service for legitimate users.

How to detect it

Look for evidence of attempted or successful denial of service rather than compromise. Relevant sources include application upload logs, email gateway logs, web/API access logs, archive-processing service logs, malware-scanning or content-indexing logs, job-queue telemetry, container/runtime metrics, EDR process telemetry, and operating system CPU accounting. Search for RAR/RAR5 files processed shortly before sustained CPU spikes, worker timeouts, job retries, queue growth, or process supervisor restarts. Investigate archive-processing processes that remain at or near 100% CPU for unusually long periods without corresponding I/O progress. Correlate repeated submissions of RAR5 archives from the same source with degraded service availability. Preserve suspicious archives for offline analysis, but do not repeatedly open or extract them on production systems. There are no named threat actors or known exploited-in-the-wild campaigns in the provided intelligence, so detection should focus on behavioral indicators: high CPU in libarchive-consuming services, repeated decompression timeouts, and anomalous RAR5 ingestion patterns.

• RAR5
• archive_read_data
• libarchive
• application/x-rar-compressed
• application/vnd.rar
• Rar!\x1A\x07\x01\x00
• 52 61 72 21 1A 07 01 00
• .rar
• rar5
• decompression timeout
• archive extraction timeout
• worker timeout
• CPU limit exceeded
• killed due to timeout
• stuck archive job
• archive processing failed
• archive_read_data failed

What your security team should do

• Prioritize inventory of internet-facing, email-facing, file-upload, artifact-processing, and security-scanning services that process RAR/RAR5 archives using libarchive or bundled libarchive copies.
• Patch libarchive through vendor-supported updates as soon as fixed packages are available, and rebuild any statically linked applications, containers, appliances, or third-party software components that embed vulnerable code.
• Apply compensating controls immediately for untrusted archive workflows: disable RAR5 where not business-critical, enforce extraction timeouts, cap CPU usage, limit concurrency, and isolate archive processing in disposable worker processes.
• Add monitoring for archive-processing workers consuming sustained high CPU, repeatedly timing out, or creating queue backlogs after handling RAR/RAR5 files.
• Retain and quarantine archive samples that trigger abnormal CPU usage or decompression timeouts so they can be analyzed without repeatedly reprocessing them in production.
• Treat repeated RAR5 submissions from the same source, account, IP address, mailbox, or integration as a potential denial-of-service attempt and rate-limit or block where appropriate.
• Because EPSS is currently low and the issue is not listed in KEV, schedule remediation based on exposure: accelerate for automated processing of untrusted files; handle lower-trust internal-only use through normal patch cycles with compensating controls.