CVE-2023-28205

What it actually does

CVE-2023-28205 is a WebKit use-after-free vulnerability affecting Safari, iOS/iPadOS, and macOS. When a vulnerable WebKit engine processes maliciously crafted web content, memory that has already been freed can be reused in an unsafe way, allowing an attacker to corrupt process memory and potentially execute arbitrary code in the context of the browser or web content process. The vulnerability is remotely reachable over the network, requires no authentication, and only requires user interaction such as opening a malicious webpage, link, embedded browser view, or attacker-controlled web content. Because WebKit is used beyond Safari in many Apple web-rendering contexts, exposure can extend to applications that display web content through Apple platform web views. Full device compromise typically requires chaining this bug with a sandbox escape or privilege escalation, but the flaw can still enable theft or manipulation of browser-accessible data and serve as an initial execution primitive.

Why it matters to the business

Successful exploitation can allow attackers to compromise Apple endpoints through web browsing activity, potentially leading to data theft, session hijacking, malware deployment, surveillance, or further lateral movement when combined with additional vulnerabilities. The issue is listed in CISA KEV, Apple reported active exploitation, and the CISA remediation deadline was 2023-05-01, so unpatched devices should be treated as high-priority exposure even though the vulnerability is older. The practical business risk is highest for organizations with unmanaged Apple devices, delayed mobile/macOS patching, high-risk users, or workflows that routinely open external links and web content.

How an attack unfolds

An attacker prepares web content that triggers the WebKit use-after-free condition. The content is hosted on a malicious website, injected into a compromised legitimate site, delivered through an advertisement, or sent directly as a link through email, messaging, social media, or another lure. When a user on a vulnerable Apple platform opens the content in Safari or another WebKit-based rendering context, WebKit mishandles memory during page processing. The attacker uses heap grooming and memory corruption techniques to gain control of execution within the affected process. From there, the attacker may run code with the privileges and sandbox restrictions of the browser content process, steal browser-accessible data, execute follow-on payloads, or chain the exploit with a sandbox escape or kernel/local privilege escalation for broader device compromise. Active exploitation was reported by Apple, and the vulnerability is tracked in KEV, so exploitation should be considered operationally realistic rather than theoretical.

How to fix it

Upgrade affected Apple products to versions that include Apple’s corrected memory management for this issue. Minimum fixed versions are Safari 16.4.1, iOS 15.7.5, iPadOS 15.7.5, iOS 16.4.1, iPadOS 16.4.1, and macOS Ventura 13.3.1; later supported versions are also expected to contain the fix. Prioritize devices that browse untrusted web content, handle sensitive data, or belong to high-risk users. Where immediate patching is not possible, reduce exposure by limiting access to untrusted websites, disabling or restricting automatic link previews, using web filtering and DNS security controls, limiting use of unmanaged browsers or embedded web views, and isolating high-risk browsing activity. Because this vulnerability was actively exploited and is in KEV, mitigation should not be considered a substitute for patching.

How to confirm the fix worked

Confirm that all affected systems are running fixed or later versions: Safari 16.4.1 or later, iOS/iPadOS 15.7.5 or later for the 15.x branch, iOS/iPadOS 16.4.1 or later for the 16.x branch, and macOS Ventura 13.3.1 or later. On macOS, validate using Software Update status, MDM inventory, Safari application version, and OS build reporting. On iOS and iPadOS, validate through MDM device inventory, OS version compliance policies, and update installation status. Test representative managed devices to ensure updates are installed and no deferral profiles are blocking remediation. For exposure validation, identify Apple devices below the fixed versions and applications that use WebKit-based rendering. For compensating controls, verify that web filtering, DNS controls, and browser isolation policies are active for devices that cannot immediately be upgraded.

Typical attack path

1. Identify users or devices likely running vulnerable versions of Safari, iOS, iPadOS, or macOS.
2. Create or acquire malicious web content that reliably triggers the WebKit use-after-free condition.
3. Deliver the content through a malicious link, compromised website, malvertising, phishing message, or embedded web view workflow.
4. Wait for a user to open or preview the crafted web content on a vulnerable Apple device.
5. Trigger memory corruption in WebKit and gain arbitrary code execution in the web content/browser process.
6. Run payload logic within the available sandbox, access browser/session data where possible, or stage additional tooling.
7. Optionally chain with another vulnerability to escape the sandbox or elevate privileges for persistent or broader compromise.
8. Exfiltrate data, deploy surveillance tooling, establish persistence, or use the compromised device as a foothold.

How to detect it

Detection is difficult because exploitation occurs through memory corruption in WebKit and may leave few stable indicators. Focus on behavior and timeline correlation rather than a single signature. Collect macOS DiagnosticReports, iOS/iPadOS crash analytics where available through device management or sysdiagnose, EDR telemetry, browser history, DNS logs, web proxy logs, email/link-protection logs, and network telemetry. Look for Safari, MobileSafari, or com.apple.WebKit.WebContent crashes involving EXC_BAD_ACCESS or KERN_INVALID_ADDRESS shortly after visits to suspicious, newly registered, compromised, or uncategorized domains. Correlate crashes with immediate follow-on behavior such as unexpected process execution, unsigned or unusual binaries, launch agents or daemons, configuration profile changes, persistence creation, credential access, suspicious outbound connections, or security tool tampering. On iOS/iPadOS, look for abnormal app crashes, unexpected device profiles, unusual battery/network activity, and any available crash logs referencing WebKit. Because active exploitation was reported and the issue is KEV-listed, any vulnerable device with suspicious WebKit crash activity followed by anomalous endpoint or network behavior should be triaged as a potential compromise.

• com.apple.WebKit.WebContent
• MobileSafari
• Safari
• WebKit
• EXC_BAD_ACCESS
• KERN_INVALID_ADDRESS
• /Library/Logs/DiagnosticReports/
• ~/Library/Logs/DiagnosticReports/
• com.apple.WebKit.WebContent_
• Safari_
• MobileSafari_
• WebContent_
• JetsamEvent
• ips
• crash

What your security team should do

• Immediately identify and remediate any Apple devices running Safari, iOS, iPadOS, or macOS versions older than the fixed releases, prioritizing internet-facing users, executives, administrators, developers, and high-risk roles.
• Treat unpatched exposure as urgent because the vulnerability is in CISA KEV, had a remediation deadline of 2023-05-01, and was reported as actively exploited in the wild.
• Use MDM or endpoint management tooling to enforce minimum OS and Safari versions and remove update deferrals that prevent installation of fixed releases.
• Hunt for signs of prior exploitation on vulnerable Apple endpoints, especially unexpected WebKit/Safari crashes followed by suspicious child processes, new persistence artifacts, unusual network connections, or post-exploitation activity.
• Review web proxy, DNS, EDR, and email security logs for users who visited suspicious or newly registered domains shortly before Safari/WebKit crashes or endpoint alerts.
• Apply stricter controls for devices that cannot be upgraded, including web filtering, isolation of high-risk browsing, blocking unknown link-preview behavior where feasible, and limiting access to sensitive applications from noncompliant devices.
• Communicate to users that unexpected links, pop-ups, or websites can compromise older Apple devices even without downloading a file, and encourage prompt reporting of suspicious browser behavior.
• For incident response, prioritize timelines around browser activity, WebKit crash logs, suspicious outbound connections, and any evidence of follow-on payload execution or persistence.