CVE-2025-24201

What it actually does

This is a WebKit memory-corruption vulnerability in Apple platforms where maliciously crafted web content can trigger an out-of-bounds write and escape the Web Content sandbox. A successful exploit can move code execution from the restricted browser/web-rendering process into a more privileged context, undermining a key isolation boundary used by Safari and other apps that render web content through WebKit. Apple describes this as a supplementary fix for an attack blocked in iOS 17.2 and reports exploitation against specific targeted individuals on iOS versions before 17.2, indicating advanced exploit-chain usage rather than opportunistic commodity exploitation.

Why it matters to the business

Compromise of a device through web content can expose sensitive communications, credentials, browser data, files accessible to the exploited process chain, and potentially enable follow-on device surveillance or persistence when combined with other vulnerabilities. Because this vulnerability is in CISA KEV with active in-the-wild exploitation and a remediation deadline of 2025-04-03, organizations should treat unpatched Apple endpoints as high-priority exposure, especially for executives, administrators, developers, legal staff, journalists, and other high-risk users. Although the EPSS score is moderate, confirmed targeted exploitation makes patch urgency higher than probability scoring alone would suggest.

How an attack unfolds

An attacker prepares web content that exercises the vulnerable WebKit code path and causes an out-of-bounds write during rendering. The content is delivered through a link, compromised website, malicious advertisement, embedded web view, or message content that causes WebKit to process attacker-controlled data. When the vulnerable device renders the content, memory corruption is used to gain control of execution inside the Web Content process. The exploit then uses the sandbox-escape condition to perform actions outside the normal Web Content sandbox. In realistic intrusions this flaw may be one stage in a larger chain, paired with additional vulnerabilities or post-exploitation tooling to access sensitive data, monitor activity, or install spyware-like capabilities. Apple has stated the issue may have been exploited in highly sophisticated attacks against specifically targeted individuals on iOS versions before 17.2.

How to fix it

Apply Apple vendor updates immediately. Fixed versions are Safari 18.3.1, iOS 15.8.4 and iPadOS 15.8.4, iOS 16.7.11 and iPadOS 16.7.11, iOS 18.3.2 and iPadOS 18.3.2, iPadOS 17.7.6, macOS Sequoia 15.3.2, visionOS 2.3.2, and watchOS 11.4. Prioritize internet-facing browsing devices, managed mobile fleets, and users at elevated risk of targeted surveillance. Where immediate patching is not possible, reduce exposure by limiting use of Safari and WebKit-based browsing, restricting unknown links and web content, disabling unnecessary web previews where administratively feasible, using device lockdown or high-risk user protections where available, and isolating unpatched devices from sensitive workflows. The provided Red Hat kernel-rt package fixed-version data does not align with the Apple WebKit vulnerability description; remediation should be validated against the authoritative vendor advisory for the actual product in use rather than relying on unrelated package names.

How to confirm the fix worked

Confirm Apple devices and browsers report versions at or above the fixed releases: Safari 18.3.1, iOS/iPadOS 15.8.4, iOS/iPadOS 16.7.11, iOS/iPadOS 18.3.2, iPadOS 17.7.6, macOS Sequoia 15.3.2, visionOS 2.3.2, or watchOS 11.4 as applicable. On managed Apple fleets, verify update compliance through MDM inventory, OS build reporting, Safari application version reporting, and configuration profiles enforcing software update installation. For macOS, validate with system version and Safari version checks; for iOS/iPadOS, validate through MDM-reported OS version and build. Reconcile asset inventory against Apple platforms that use WebKit, including non-Safari apps with embedded web views. Treat any device below the fixed versions as exposed, even if Safari is not the default browser, because WebKit is used broadly across Apple web-rendering contexts.

Typical attack path

1. Identify a target using an affected Apple platform or Safari/WebKit version.
2. Deliver malicious web content through a link, compromised site, ad network, embedded web view, or message-rendered content.
3. Cause the target device or application to render the crafted content using WebKit.
4. Trigger the out-of-bounds write to corrupt memory in the Web Content process.
5. Achieve code execution or control flow manipulation inside the WebKit rendering context.
6. Break out of the Web Content sandbox to perform unauthorized actions with elevated access relative to the renderer.
7. Use additional exploit-chain components or post-exploitation tooling to collect data, surveil activity, or maintain access.

How to detect it

Detection is difficult because sophisticated WebKit exploit chains often leave limited on-device evidence and may not produce stable, public indicators. Hunt across macOS unified logs, Safari history and website data, crash reports, endpoint telemetry, MDM security events, network proxy logs, DNS logs, and mobile threat defense telemetry. Focus on unexplained crashes or restarts of WebKit rendering processes, especially near visits to unusual domains or message/link interactions; repeated EXC_BAD_ACCESS or KERN_INVALID_ADDRESS crashes in WebKit-related processes; sandbox violation messages involving WebContent; unexpected configuration profiles, VPN settings, root certificates, device management enrollment changes, or enterprise-signed apps; and outbound connections to unfamiliar infrastructure shortly after WebKit crashes. For iOS and iPadOS, collect sysdiagnose and crash logs where available and review MDM/mobile threat defense alerts. For macOS, review Unified Logging, DiagnosticReports, browser artifacts, and EDR process/network telemetry. Absence of these artifacts does not rule out exploitation, particularly for targeted spyware-style operations.

• com.apple.WebKit.WebContent
• com.apple.WebKit.Networking
• com.apple.Safari
• MobileSafari
• /Library/Logs/DiagnosticReports/com.apple.WebKit.WebContent_
• ~/Library/Logs/DiagnosticReports/com.apple.WebKit.WebContent_
• /var/mobile/Library/Logs/CrashReporter/
• EXC_BAD_ACCESS (SIGSEGV)
• KERN_INVALID_ADDRESS
• Sandbox: com.apple.WebKit.WebContent
• WebContent sandbox
• Safari 18.3
• iOS 17.1
• iOS 17.2
• iOS 18.3.1
• iPadOS 17.7.5
• macOS 15.3.1

What your security team should do

• Immediately inventory Apple endpoints and prioritize patching all devices below the fixed versions, with special handling for high-risk users and privileged personnel.
• Use MDM to enforce installation of the relevant iOS, iPadOS, macOS, Safari, visionOS, and watchOS updates and monitor compliance until there are no remaining vulnerable versions.
• For any device that cannot be patched promptly, apply temporary controls: restrict unknown web content, limit risky browsing, disable unnecessary link previews where possible, and avoid sensitive operations on the device.
• Conduct targeted threat hunting for WebKit crashes, Safari or WebContent anomalies, suspicious profiles, unexpected persistence artifacts, and unusual outbound network activity around the period before patching.
• Escalate forensic review for devices belonging to high-risk individuals if unexplained WebKit crashes, device instability, suspicious configuration profiles, or anomalous network behavior are observed.
• Because this is KEV-listed and known exploited, document remediation status against the 2025-04-03 CISA due date and maintain exception tracking for any unsupported or unpatched devices.
• Validate product mapping carefully; do not substitute unrelated downstream package versions for Apple WebKit fixed versions unless the vendor explicitly confirms applicability.