CVE-2022-32893

What it actually does

This is a WebKit memory corruption vulnerability caused by an out-of-bounds write while processing maliciously crafted web content. A remote attacker can trigger the flaw through a browser or any application that embeds WebKit, causing memory to be overwritten outside the intended buffer. Successful exploitation can result in arbitrary code execution in the context of the affected browser, web content process, or embedding application. Because exploitation requires a victim to process attacker-controlled web content, common entry points include malicious links, compromised websites, malicious advertisements, HTML email previews, and in-app web views. Apple reported active exploitation in the wild, and the vulnerability is listed in CISA KEV with a remediation due date of 2022-09-08.

Why it matters to the business

Exploitation can allow an attacker to compromise user workstations, mobile devices, or applications that render web content, potentially leading to data theft, credential capture, surveillance, malware installation, and follow-on access into enterprise services. The impact is high because no authentication is required and exploitation can occur through normal browsing or content preview behavior. Since this issue has been actively exploited and is in CISA KEV, unpatched systems should be treated as a priority exposure even though the public EPSS score is moderate. The affected WebKit ecosystem can also extend beyond Safari to Linux applications using webkit2gtk, increasing operational exposure in desktop, kiosk, embedded, and application-runtime environments.

How an attack unfolds

An attacker prepares web content that exercises the vulnerable WebKit code path and causes an out-of-bounds write. The attacker then delivers that content through a website, redirected link, compromised legitimate page, malicious advertisement, phishing message, or any application workflow that renders attacker-controlled HTML or JavaScript using WebKit. When the victim visits or previews the content, WebKit corrupts memory. A reliable exploit shapes process memory so the overwrite redirects execution to attacker-controlled code. The attacker’s payload then runs with the privileges of the affected browser content process or embedding application. In real intrusions, this type of browser-engine exploit is commonly paired with a sandbox escape, privilege escalation, persistence mechanism, or post-exploitation implant to obtain durable access and collect data. Public reporting confirms active exploitation, so defenders should assume exploitation may have been targeted and stealthy rather than noisy or opportunistic.

How to fix it

Apply vendor fixes immediately across all affected products. For Apple platforms, upgrade to iOS 15.6.1 or later, iPadOS 15.6.1 or later, macOS Monterey 12.5.1 or later, and Safari 15.6.1 or later, or any newer supported release. For Linux webkit2gtk packages listed in the input, update to the fixed package versions or later: Debian 10, 11, 12, and 13: webkit2gtk 2.20.3-1 or later; Ubuntu 16.04 LTS: webkit2gtk 2.20.3-0ubuntu0.16.04.1 or later; Ubuntu 18.04 LTS: webkit2gtk 2.20.3-0ubuntu0.18.04.1 or later. Where immediate patching is not possible, reduce exposure by disabling or restricting untrusted web content rendering in affected applications, blocking high-risk browsing from vulnerable hosts, preventing automatic preview of remote HTML content, using browser isolation for risky destinations, and limiting execution rights for applications embedding WebKit. Mitigations should be temporary because memory-corruption browser-engine vulnerabilities are difficult to fully neutralize without patching.

How to confirm the fix worked

Confirm the installed browser, operating system, and WebKit/webkit2gtk package versions are at or above the fixed releases. On Apple platforms, verify OS and Safari versions through system inventory, MDM, or software update records, and ensure devices are not pinned to vulnerable builds. On Debian or Ubuntu systems, validate package status with package-management inventory such as `dpkg -l`, `apt-cache policy`, or vulnerability scanner output, confirming that webkit2gtk is at the vendor-fixed version or later. Test representative applications that embed WebKit to ensure they are linked against the patched library. Re-run authenticated vulnerability scans after patching and confirm the finding is closed. For higher-assurance validation, check that crash logs for Safari, WebKit WebContent processes, or WebKitWebProcess do not continue after the patch date when visiting normal web content, and confirm no vulnerable copies of WebKit are bundled inside third-party applications outside the system package manager.

Typical attack path

1. Identify users, devices, or applications likely to run vulnerable WebKit or webkit2gtk versions.
2. Create or acquire malicious web content that triggers the out-of-bounds write condition.
3. Deliver the content through phishing, a malicious site, a compromised legitimate site, malicious advertising, or an embedded web-view workflow.
4. Convince or cause the victim to open, preview, or browse to the attacker-controlled content.
5. Trigger memory corruption inside WebKit during content parsing or script execution.
6. Execute attacker-controlled code in the browser, WebKit content process, or embedding application context.
7. Optionally chain with a sandbox escape or local privilege escalation to broaden access.
8. Deploy malware, steal session data or credentials, surveil user activity, or pivot to additional systems.

How to detect it

There are no universally reliable public exploit strings for this vulnerability, so detection should focus on behavioral and forensic evidence around WebKit memory-corruption exploitation. Review endpoint crash reports for Safari, com.apple.WebKit.WebContent, WebKitWebProcess, MiniBrowser, Evolution, Epiphany/GNOME Web, or other applications embedding WebKit around the time users visited suspicious websites or opened HTML content. On macOS, collect DiagnosticReports and Unified Logs for WebKit crashes, especially EXC_BAD_ACCESS, KERN_INVALID_ADDRESS, segmentation faults, or repeated crashes involving JavaScriptCore or WebCore. On Linux, review /var/log/syslog, /var/log/apport.log, systemd journal, and /var/crash for WebKitWebProcess crashes or segmentation faults in libwebkit2gtk, JavaScriptCore, or WebCore. Correlate crash timestamps with proxy, DNS, secure web gateway, and browser history records for unusual redirects, newly registered domains, URL shorteners, advertising chains, or unsolicited links. In EDR telemetry, look for abnormal child processes spawned by browsers or WebKit-embedding applications, unexpected shell execution, scripting interpreters, downloads, credential-access behavior, persistence creation, or outbound connections immediately after a WebKit crash. For Apple endpoints, also review mobile device management and endpoint telemetry for devices that were not updated to the fixed versions before the KEV deadline. Because active exploitation has been reported, absence of a known IOC should not be treated as proof of no compromise.

• com.apple.WebKit.WebContent
• Safari_*.crash
• com.apple.WebKit.WebContent_*.crash
• com.apple.WebKit.WebContent_*.ips
• ~/Library/Logs/DiagnosticReports/Safari_*.crash
• ~/Library/Logs/DiagnosticReports/com.apple.WebKit.WebContent_*.crash
• /Library/Logs/DiagnosticReports/Safari_*.crash
• /Library/Logs/DiagnosticReports/com.apple.WebKit.WebContent_*.crash
• EXC_BAD_ACCESS
• KERN_INVALID_ADDRESS
• JavaScriptCore
• WebCore
• WebKitWebProcess
• WebKitWebProcess segfault
• libwebkit2gtk
• libjavascriptcoregtk
• /var/log/apport.log
• /var/crash/_usr_lib_*WebKitWebProcess*.crash
• /var/crash/*webkit2gtk*.crash
• /usr/lib/*/webkit2gtk-*
• Segmentation fault.*WebKitWebProcess
• kernel:.*WebKitWebProcess.*segfault

What your security team should do

• Prioritize remediation as urgent because the vulnerability is actively exploited in the wild and is listed in CISA KEV; the KEV remediation deadline was 2022-09-08.
• Inventory all Apple endpoints, Safari installations, and Linux applications or systems using webkit2gtk, including embedded browsers, kiosks, thick clients, and desktop applications.
• Patch Apple platforms to iOS 15.6.1, iPadOS 15.6.1, macOS Monterey 12.5.1, Safari 15.6.1, or later supported releases, and patch Linux webkit2gtk packages to the fixed vendor versions or later.
• Hunt for suspicious WebKit, Safari, and WebKitWebProcess crashes before the patch date and correlate them with browsing history, proxy logs, DNS logs, EDR telemetry, and any subsequent process execution.
• Treat unexplained WebKit crashes followed by network beacons, script execution, new persistence, or credential-access behavior as potential compromise requiring endpoint triage.
• Apply temporary controls for systems awaiting patching, including browser isolation, blocking unknown or newly registered domains, restricting HTML previews, and limiting use of vulnerable embedded web views.
• Review high-risk users and devices for signs of targeted exploitation, especially where suspicious links, unusual redirects, or repeated browser crashes preceded abnormal authentication or endpoint behavior.
• Ensure EDR and MDM coverage includes Apple endpoints and Linux desktop or application hosts that may not be covered by traditional server patch workflows.