How do you patch or mitigate CVE-2022-30333 (RARLAB UnRAR Directory Traversal)?

CISA’s required action for CVE-2022-30333 is to apply updates per vendor instructions. In practice, find every instance of RARLAB UnRAR in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What you need to confirm before patching

CVE-2022-30333 is a directory traversal flaw in RARLAB UnRAR, so the first task is simple inventory, not remediation. Confirm where UnRAR is installed, where it is embedded in another product or automation flow, and whether any internet-facing service can invoke it. For vulnerability triage and exploited flaw handling, use the Zero-Day and Exploited Vulnerabilities Guide to structure the response.

Because CISA says to apply vendor updates, your exposure check should also identify systems where that is not immediately possible. That includes legacy hosts, appliances, packaged software, and build or extraction jobs that depend on the library. If the product is wrapped inside another application, the patch decision often belongs to the vendor of that application as much as to RARLAB.

For official vulnerability records and remediation context, verify the entry in the CVE Program and cross-check exploitation status in the CISA Known Exploited Vulnerabilities Catalog.

How to apply the fix when you can patch

The preferred action is to apply the vendor security update or documented mitigation on every affected instance. Treat this as a fleet task, not a one-off fix, because UnRAR is often present in more than one place and may be embedded in third-party tooling. If you need a broader patch workflow, the Vulnerability Management Guide is the most practical route for asset scope, prioritisation, and verification.

Patch validation matters as much as installation. Confirm the corrected package is actually running, confirm the vulnerable binary is no longer reachable through scheduled jobs or application containers, and record which systems were updated versus removed. For teams that rely on KEV-driven urgency, CISA and exploit likelihood signals should both influence queue order, especially when remediation windows are tight.

If you need to track likelihood of exploitation while waiting on maintenance windows, use FIRST EPSS alongside KEV status. It helps you separate “known exploited” from “likely to be exploited soon,” which is useful when several urgent issues compete for the same maintenance slot.

What to do if patching must wait

If you cannot patch immediately, the best mitigation is to remove exposure. That usually means taking the product out of service, restricting it to trusted internal networks, or blocking any path that allows untrusted users or automated flows to reach the vulnerable parser. For traversal flaws, exposure reduction is often more effective than trying to “watch” the issue in place.

Where business dependency prevents removal, reduce the blast radius with tight placement, limited privileges, and strong network boundaries. The risk is not only arbitrary file access, but also secondary access to scripts, keys, configuration files, or other material that may sit near the vulnerable path. In practice, that means treating the affected service as a candidate for isolation until the vendor fix is in place.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	CVE patching and exposed-flaw response are continuous vulnerability management tasks.
Recommendation — Prioritize, remediate, and verify exposed vulnerabilities on a recurring cadence.
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	Exploit-driven patch triage depends on a defined risk-based remediation strategy.
	DE.CM-01 — Networks and Systems Are Monitored	Post-remediation review of logs and exposure needs monitoring for signs of exploitation.
Recommendation — Use a risk-based strategy to rank exploited vulnerabilities and set remediation urgency. Monitor affected systems for evidence of active exploitation and suspicious file access.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Applying vendor updates and mitigations is direct flaw remediation for this CVE.
	SI-4 — System Monitoring	Checking logs for earlier exploitation requires active security monitoring.
Recommendation — Apply vendor-provided fixes or mitigations and verify vulnerable components are removed or updated. Inspect logs and alerts for indicators that the flaw was exploited before remediation.

Practitioner Guidance

What to prioritise: Patch or isolate every instance of UnRAR that is internet-facing or embedded in a user-reachable workflow before you spend time on fine-grained tuning. Directory traversal issues become materially worse when the parser is reachable from external input.

What to verify: After remediation, confirm the vulnerable binary, library, or bundled component is gone from the reachable execution path, not just that a ticket was closed. If the software remains installed, verify that its invocation path cannot be triggered from exposed services or uploads.

What to measure: Track time to identify every deployment, time to apply vendor instructions, and time to remove exposure where patching is delayed. Those three timings tell you whether the response is operationally real or only documented.

Practitioner takeaway: For an exploited traversal flaw, the real decision is usually patch versus exposure removal, not patch versus wait and observe. If you cannot prove the vulnerable parser is no longer reachable, you have not finished the remediation.