How do you patch or mitigate CVE-2022-22620 (Apple iOS, iPadOS, and macOS Webkit Use-After-Free)?

CISA’s required action for CVE-2022-22620 is to apply updates per vendor instructions. In practice, find every instance of Apple iOS, iPadOS, and macOS 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 actually needs to be fixed on affected Apple devices

CVE-2022-22620 is a WebKit use-after-free issue in Apple iOS, iPadOS, and macOS. For patching, the practical task is straightforward: identify every Apple device running those operating systems, apply the vendor update or documented mitigation, and verify that the fix is actually present rather than assumed from deployment status alone. Use the vendor advisory for exact build guidance.

Because this was exploited in the wild, remediation should be treated as a priority exposure, not a routine maintenance item. If a device cannot be updated immediately, the fallback is to remove internet exposure or take the product out of service until you can apply the Apple security update. That is a containment decision, not a long-term substitute for patching.

For Apple mobile fleets, Mobile Device Security Guide is the best general reference point for how enterprise-owned and BYOD devices should be inventoried, enrolled, and kept patchable without losing oversight.

How to reduce exposure before and after the update

The first control is scope. Confirm where Apple iOS, iPadOS, and macOS are present, including unmanaged endpoints that may not report cleanly to central tooling. Then decide whether the device can be patched in place, isolated until maintenance, or removed from service. For devices with remote access paths, internet-facing exposure increases the urgency because WebKit issues are often reachable through ordinary browsing workflows.

When patching is delayed, use compensating controls that reduce attacker reach rather than merely slowing user activity. That usually means limiting internet access, tightening browser use on high-risk systems, and ensuring the affected endpoints are not used for sensitive workflows that would be difficult to unwind if compromise occurred. For broader prioritisation discipline, Vulnerability Management Guide is the most useful internal reference for asset scoping, KEV-driven prioritisation, exceptions, and verification.

External sources should stay open beside the vendor advisory and the KEV catalogue. The CISA Known Exploited Vulnerabilities Catalog tells you when exploitation has been confirmed, while the CVE Program and NIST National Vulnerability Database help you anchor the record and correlate it with your own asset inventory.

What to look for after patching or mitigation

After remediation, review browser, endpoint, and security telemetry for signs of earlier exploitation. A KEV entry is not just a patching signal, it is also a compromise-check signal. If any device was exposed while unpatched, validate whether the user profile, browser state, or adjacent systems show suspicious execution, persistence, or unusual outbound activity. If the device handled privileged work, extend the review to credentials and sessions that may have been exposed during the window of risk.

A useful habit is to separate “patched” from “cleared.” Patched means the software is fixed. Cleared means you have enough telemetry to believe the flaw was not already used against that endpoint, or that you have contained the aftermath. Where the response workflow needs more depth on weak software patterns, CWE Top 25 Guide helps explain why use-after-free flaws are high-value targets for exploit development.

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, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	CVE remediation depends on asset scope, prioritisation, and timely patch verification.
	CIS-12 — Network Infrastructure Management	Temporary isolation or reduced exposure is a key compensating control when patching must wait.
Recommendation — Prioritise KEV-listed Apple devices and verify remediation in your vulnerability workflow. Restrict internet exposure for unpatched Apple endpoints until updates are installed.
NIST CSF 2.0	RS.MA-01 — Incident Management Improvements	Post-patch review for signs of earlier exploitation is part of recovery and response follow-up.
Recommendation — Review affected endpoints for compromise indicators after remediation.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The subject is direct vulnerability remediation for an exploited software flaw.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation and validation require active vulnerability monitoring and verification.
Recommendation — Apply vendor security updates and document the remediation outcome. Scan Apple assets to confirm vulnerable versions are removed from service.
OWASP ASVS	V13 — Configuration	Mitigation and secure deployment state depend on correct system and browser configuration.
Recommendation — Validate endpoint configuration and update state before returning devices to normal use.

Practitioner Guidance

What to prioritise: Put every exposed Apple device into one of three buckets: patched, temporarily isolated, or taken out of service. Do not let “scheduled for update” count as risk reduction if the endpoint is still reachable from the internet.

What to verify: Confirm the vendor update is installed on the actual device state, not only in the management console. Then verify whether any device that remained exposed has logs, telemetry, or user reports that justify a deeper compromise review.

Decision rule: If you cannot patch quickly, containment must be strong enough to reduce exploitability, not just inconvenience users. Once the update is applied, the remaining question is whether the device was touched before remediation and whether any credentials or sessions used on it need review.

Practitioner takeaway: For KEV-class browser flaws, the security decision is never just “apply the patch”; it is “patch, contain any delay, and prove the device was not already used as an entry point.”