CVE-2022-22620

What it actually does

CVE-2022-22620 is a WebKit use-after-free vulnerability affecting Safari, iOS, iPadOS, and macOS. When a vulnerable device processes maliciously crafted web content, WebKit can incorrectly access memory after it has been freed, allowing an attacker to corrupt memory and potentially execute arbitrary code in the context of the browser or web content process. Because WebKit is used broadly across Apple browsing and in-app web rendering, exploitation can occur through Safari or applications that display attacker-controlled web content.

Why it matters to the business

Successful exploitation can compromise Apple endpoints through a malicious website, link, advertisement, or embedded web content, potentially leading to data theft, malware installation, device compromise, and follow-on access to accounts or enterprise resources. Apple reported active exploitation in the wild, and this vulnerability is listed in CISA KEV with a remediation deadline of 2022-02-25, making unpatched devices a high-priority exposure even though the issue is older. Broad Apple ecosystem usage means exposure may include managed Macs, iPhones, iPads, Safari users, and applications relying on WebKit-rendered content.

How an attack unfolds

An attacker prepares web content that triggers the WebKit memory management flaw. The victim is induced to open the content through Safari, an in-app browser, a message link, email link, compromised website, malvertising chain, or other web-rendering path. When the vulnerable WebKit engine parses or executes the crafted content, a freed memory object is reused in an unsafe way, allowing memory corruption. A reliable exploit can use this condition to gain code execution inside the WebKit content process. In real-world attacks, browser code execution is commonly paired with sandbox escape, privilege escalation, persistence, or surveillance tooling to achieve broader device compromise. Apple confirmed active exploitation, and reporting associates exploitation activity with campaigns including the Interlock ransomware campaign, so defenders should treat suspicious browser crashes, unusual post-exploitation behavior, and unpatched Apple devices as potentially significant.

How to fix it

Upgrade affected Apple products to fixed or later versions immediately. Apple fixed the issue in macOS Monterey 12.2.1, iOS 15.3.1, iPadOS 15.3.1, and Safari 15.3 with builds 16612.4.9.1.8 and 15612.4.9.1.8. Where available, upgrade to the latest supported iOS, iPadOS, macOS, and Safari releases rather than only the minimum fixed version, because later releases include additional WebKit and platform hardening. For managed fleets, enforce OS and browser minimum versions through MDM or endpoint management, block or quarantine unsupported devices, and verify that embedded WebKit-dependent applications run on a patched OS/browser stack. If immediate patching is not possible, reduce exposure by limiting access to untrusted web content, disabling or restricting unmanaged browsers where feasible, applying web filtering, isolating high-risk browsing, and prioritizing patching for users with elevated access, executives, developers, help desk staff, and externally exposed roles.

How to confirm the fix worked

Confirm remediation by verifying product versions: iOS and iPadOS should be 15.3.1 or later, macOS Monterey should be 12.2.1 or later, and Safari should be 15.3 with build 16612.4.9.1.8 / 15612.4.9.1.8 or later. Use MDM inventory, endpoint management, vulnerability scanners, or local system checks to confirm no managed devices remain on vulnerable versions. On macOS, validate Safari and OS versions from system inventory or command-line version reporting; on iOS and iPadOS, validate through MDM device compliance records. Confirm patch compliance across both user-facing Safari installations and devices where WebKit is used by other applications. After patching, review recent crash logs and EDR telemetry for pre-patch suspicious WebKit activity to determine whether incident response follow-up is required.

Typical attack path

1. Attacker identifies users or devices running vulnerable Safari, iOS, iPadOS, or macOS versions.
2. Attacker hosts or delivers maliciously crafted web content designed to trigger the WebKit use-after-free condition.
3. Victim opens the content through Safari, MobileSafari, an embedded WebKit view, a messaging app preview, email link, or redirected browser session.
4. The crafted content causes memory corruption in WebKit after a freed object is accessed.
5. Exploit code achieves arbitrary code execution in the browser or web content process context.
6. Attacker attempts follow-on actions such as escaping the browser sandbox, stealing browser/session data, installing payloads, profiling the device, or moving toward enterprise resources.
7. Attacker may clean up delivery artifacts or rely on ephemeral browser activity, leaving limited forensic evidence beyond crashes, web history, network traces, and endpoint telemetry.

How to detect it

Detection is challenging because browser memory corruption exploits may leave few durable artifacts and can be delivered through ordinary web traffic. Focus on correlation rather than a single indicator: identify vulnerable Apple devices, then review activity before patching for WebKit or Safari crashes, abnormal browser child processes, suspicious network redirects, unknown payload downloads, and post-exploitation behavior. Useful log sources include macOS Unified Logs, DiagnosticReports crash logs, Safari history where available, EDR process and file telemetry, MDM compliance records, DNS logs, secure web gateway/proxy logs, firewall logs, and mobile threat defense telemetry. On macOS, look for crash reports involving Safari, com.apple.WebKit.WebContent, com.apple.WebKit.Networking, or WebKit processes with EXC_BAD_ACCESS, KERN_INVALID_ADDRESS, heap corruption, or JavaScriptCore/WebCore stack traces, especially after visits to unfamiliar domains. On iOS and iPadOS, review MDM/mobile threat defense alerts, device analytics if collected, and signs of unusual crashes or suspicious profiles/apps following web activity. Investigate any sequence where a WebKit crash is followed by unexpected process execution, persistence creation, profile installation, credential access, unusual outbound connections, or security control tampering. Because public, stable IOCs for this vulnerability are limited, prioritize behavioral detection and historical scoping over exact-match indicators.

• com.apple.WebKit.WebContent
• com.apple.WebKit.Networking
• com.apple.WebKit.GPU
• MobileSafari
• Safari
• WebKit
• JavaScriptCore
• WebCore
• EXC_BAD_ACCESS
• KERN_INVALID_ADDRESS
• Use after free
• heap corruption
• /Library/Logs/DiagnosticReports/
• ~/Library/Logs/DiagnosticReports/
• /private/var/mobile/Library/Logs/CrashReporter/
• Safari_*.crash
• com.apple.WebKit.WebContent_*.crash
• MobileSafari_*.ips
• JetsamEvent
• Apple iOS, iPadOS, and macOS Webkit Use-After-Free Vulnerability

What your security team should do

• Treat this as high priority for any remaining vulnerable Apple devices because it is in CISA KEV and was reported as actively exploited in the wild.
• Immediately inventory Safari, iOS, iPadOS, and macOS versions across managed and unmanaged-access populations.
• Enforce minimum fixed versions: macOS Monterey 12.2.1, iOS 15.3.1, iPadOS 15.3.1, and Safari 15.3 build 16612.4.9.1.8 / 15612.4.9.1.8 or later; preferably update to the latest supported releases.
• Prioritize patching devices used by privileged users, administrators, developers, finance personnel, executives, and users frequently exposed to external links or web content.
• Search historical endpoint, proxy, DNS, EDR, and crash telemetry for suspicious WebKit crashes or browser activity before patch deployment.
• Review web proxy and DNS logs for unusual redirects, newly registered domains, malvertising patterns, or suspicious browsing immediately preceding WebKit crashes.
• Where feasible, isolate or restrict internet browsing from unpatched Apple devices until remediation is complete.
• Ensure incident response playbooks account for browser-based exploitation on Apple devices, including collection of crash logs, unified logs, browser history, network telemetry, and EDR artifacts.
• Monitor threat intelligence for WebKit exploit chains and campaign reporting, including activity associated with Interlock ransomware references, while avoiding reliance on a single IOC set because exploit artifacts may vary widely.