CVE-2022-48503

What it actually does

This is a WebKit memory-corruption vulnerability reachable through processing malicious web content. Because the vulnerable component parses attacker-controlled HTML, JavaScript, CSS, media, or related browser content, a crafted page can corrupt memory and redirect execution flow, potentially allowing arbitrary code execution in the context of the browser or WebKit content process. The CVSS vector indicates network reachability, no required authentication, low attack complexity, required user interaction, and high confidentiality, integrity, and availability impact. Apple addressed the issue with improved bounds checking in tvOS 15.6, watchOS 8.7, iOS 15.6, iPadOS 15.6, macOS Monterey 12.5, and Safari 15.6. The supplied package metadata also lists curl/curl GIT as fixed at commit 72cf468d459d29e5366e416c014faaaf281dfa2d; organizations should validate applicability because the vulnerability description and fixed Apple versions point to WebKit/Safari platform exposure.

Why it matters to the business

Successful exploitation can allow an attacker to compromise a user device after the user visits or is redirected to malicious web content, exposing sensitive data, enabling malware installation, session theft, surveillance, or follow-on access to business applications. This vulnerability is listed in CISA KEV and marked as actively exploited in the wild, with a remediation due date of 2025-11-10, so it should be treated as an operationally urgent patching item despite the moderate EPSS value. Mobile devices, macOS endpoints, Safari users, embedded WebKit consumers, and Apple TV or watchOS assets may be affected where they remain below the fixed versions.

How an attack unfolds

An attacker prepares a malicious web page or web-delivered payload that triggers the flawed WebKit bounds-checking condition. The attacker then lures a target to the content through phishing, malvertising, compromised legitimate websites, in-app web views, messaging links, or drive-by redirects. When the affected Apple platform or Safari processes the content, memory corruption occurs and the attacker’s payload may execute within the WebKit content process. Depending on platform mitigations and exploit chain quality, the attacker may then attempt sandbox escape, persistence, credential or token theft, surveillance, or installation of additional malware. The vulnerability is in the Known Exploited Vulnerabilities catalog and has been reported as exploited in the wild, so investigation should include both direct browser activity and evidence of chained post-exploitation behavior.

How to fix it

Upgrade affected Apple platforms to fixed or later versions: iOS 15.6 or later, iPadOS 15.6 or later, macOS Monterey 12.5 or later, Safari 15.6 or later, tvOS 15.6 or later, and watchOS 8.7 or later. Prefer the latest supported OS and browser versions rather than only the minimum fixed release, because later releases include additional WebKit hardening and related security fixes. For software or embedded products that vendor WebKit or use Apple WebKit frameworks, apply the vendor-provided security update and rebuild affected applications where required. Where the supplied package metadata is applicable, update curl/curl GIT builds to include commit 72cf468d459d29e5366e416c014faaaf281dfa2d or later; validate this separately against the product’s advisory because the primary vulnerability details indicate Apple WebKit exposure. If immediate patching is not possible, reduce exposure by restricting untrusted browsing on vulnerable systems, blocking known malicious domains, isolating high-risk devices, using managed browser controls, disabling unnecessary preview/rendering of untrusted links where feasible, and prioritizing vulnerable devices used by privileged users or executives.

How to confirm the fix worked

Confirm that all Apple devices and browsers report fixed or later versions: iOS/iPadOS 15.6+, macOS Monterey 12.5+, Safari 15.6+, tvOS 15.6+, and watchOS 8.7+. Use MDM, endpoint management, software inventory, and vulnerability management tooling to identify devices below those versions. Verify Safari and WebKit-related packages are updated after OS patching because browser and framework updates may be OS-coupled. For source-based or embedded builds, confirm the fixed commit 72cf468d459d29e5366e416c014faaaf281dfa2d or a vendor-equivalent patch is present if the curl/curl metadata applies. Validate mitigation effectiveness by confirming vulnerable versions no longer appear in asset inventory, users cannot run unsupported browser versions, and no managed devices remain outside patch-compliance policy. For suspected exploitation, correlate browser crash telemetry, suspicious web navigation, endpoint alerts, and post-exploitation indicators around the time a vulnerable WebKit process rendered untrusted content.

Typical attack path

1. Identify targets using vulnerable Apple operating systems, Safari versions, or software embedding vulnerable WebKit components.
2. Host or inject malicious web content designed to trigger the WebKit memory-corruption condition.
3. Deliver the link or redirect through phishing, messaging, malvertising, watering-hole sites, compromised pages, or in-app browser flows.
4. Wait for the victim to open or render the malicious content.
5. Trigger memory corruption during web-content processing and execute attacker-controlled code in the browser/WebKit process context.
6. Optionally chain with a sandbox escape, privilege escalation, or persistence technique to gain broader device control.
7. Perform objectives such as data theft, session hijacking, surveillance, malware deployment, or lateral movement through user-accessible services.

How to detect it

Because exploitation occurs through memory corruption in web-content processing, there may be no single reliable network or file indicator. Focus on evidence chains: vulnerable Apple/Safari version present; visit, redirect, or preview of suspicious web content; crash or abnormal termination of WebKit/Safari content processes; and follow-on endpoint behavior such as unexpected persistence, new profiles, unusual outbound connections, credential access, or security control tampering. Relevant log sources include macOS Unified Logs, Safari history and diagnostic logs, CrashReporter reports, MDM compliance and device analytics, EDR process telemetry, DNS/proxy/web gateway logs, email security logs for delivered links, and mobile-device security telemetry where available. Hunt for crashes involving WebKit or Safari Web Content with EXC_BAD_ACCESS, KERN_INVALID_ADDRESS, SIGSEGV, heap corruption, or out-of-bounds-style symptoms, particularly immediately after navigation to unfamiliar domains. Correlate those events with known active exploitation reporting, user reports of unexpected redirects or browser crashes, and any subsequent suspicious process launches or persistence changes. On iOS/iPadOS/watchOS/tvOS, available forensic visibility is more limited, so prioritize MDM version compliance, device analytics/crash logs, suspicious link delivery telemetry, and indicators of post-compromise behavior. Treat repeated WebKit crashes on vulnerable versions as suspicious but not conclusive without corroborating web, endpoint, or network evidence.

• com.apple.WebKit.WebContent
• Safari Web Content
• WebKit
• WebKit.framework
• /System/Library/Frameworks/WebKit.framework
• /System/Library/StagedFrameworks/Safari/WebKit.framework
• /Library/Logs/DiagnosticReports/Safari_
• /Library/Logs/DiagnosticReports/com.apple.WebKit.WebContent_
• ~/Library/Logs/DiagnosticReports/Safari_
• ~/Library/Logs/DiagnosticReports/com.apple.WebKit.WebContent_
• EXC_BAD_ACCESS
• KERN_INVALID_ADDRESS
• SIGSEGV
• EXC_BAD_INSTRUCTION
• JavaScriptCore
• libsystem_malloc
• malloc: Heap corruption detected
• WebProcessProxy::processDidTerminate
• com.apple.Safari

What your security team should do

• Prioritize patching because this vulnerability is in CISA KEV, is reported as actively exploited in the wild, and has a KEV remediation deadline of 2025-11-10.
• Inventory all Apple endpoints, mobile devices, Safari installations, and applications that embed WebKit; identify anything below the fixed versions.
• Deploy the latest supported Apple OS and Safari updates, not just the minimum fixed versions, especially for internet-facing, executive, developer, and privileged-user devices.
• Use MDM or endpoint management to enforce minimum OS/browser versions and block devices that cannot be updated from accessing sensitive services.
• Review recent WebKit, Safari, and browser-content-process crashes on unpatched devices for signs of exploitation or exploit attempts.
• Hunt for suspicious browsing activity followed by process crashes, new persistence, unusual child processes, credential access, or outbound connections from affected endpoints.
• Apply web filtering, DNS security, and email/link protection controls to reduce exposure to malicious web content while patching completes.
• If using source-based or embedded package inventories, validate whether the listed curl/curl GIT fixed commit applies and reconcile the apparent metadata mismatch with vendor advisories.
• For any device with credible exploitation indicators, preserve logs, isolate the device, collect forensic artifacts, rotate exposed credentials, and consider full device rebuild or vendor-guided remediation.