Is CVE-2023-37450 (Apple Multiple Products WebKit Code Execution) being exploited in the wild?

Yes. CISA added CVE-2023-37450 to its Known Exploited Vulnerabilities catalogue on 13 July 2023, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Apple iOS, iPadOS, macOS, and Safari WebKit contain an unspecified vulnerability that leads to code execution when processing maliciously crafted web content.

What CISA’s KEV listing means for this WebKit flaw

A KEV listing is the strongest practical signal that a vulnerability is not just theoretical. For CVE-2023-37450, the operational question is not whether the bug exists, but whether the affected Apple products are exposed to malicious web content and whether the organisation can verify patch status quickly enough to reduce the window for drive-by exploitation.

When a browser engine flaw reaches active exploitation status, the first control is inventory. You need to know which iPhones, iPads, Macs and Safari installations are in service, which are internet-facing by design, and which users routinely browse untrusted content. That is the exposure profile that determines urgency, not the product name alone.

For teams that manage browser estate centrally, the relevant governance problem is not simply “is Safari installed”, but whether update enforcement, device compliance checks and user deferral are strong enough to close the gap after a KEV advisory appears. CISA Known Exploited Vulnerabilities Catalog is the authoritative source for KEV status and remediation timing, while the vendor advisory should be used for Apple-specific version and fix details.

How code execution through malicious web content becomes a practical attack path

WebKit flaws matter because they sit in the content-rendering path that users trigger constantly and often automatically. If an attacker can make a user open a malicious page, load a tainted ad, or visit a compromised site, the browser engine itself can become the execution vector before any application-layer control has a chance to intervene.

This is why exploitation-in-the-wild for browser engines is especially concerning on managed endpoints. The attacker does not need privileged access up front; they need only a delivery channel into web content and a flaw that turns parsing or rendering into code execution. That can make the browser the initial foothold for later credential theft, session theft or malware installation.

For practitioners, the key distinction is between a general browser bug and one that is already being used operationally. If the issue is on the KEV catalogue, treat it as an active exploitation problem first and a patch-management problem second. The most useful external reference for triage is the NIST National Vulnerability Database, which helps correlate the CVE record with broader vulnerability data once you have confirmed the Apple advisory.

What to do when you cannot patch every device immediately

Where patching is delayed by change control, user dependency or device ownership complexity, the fallback is exposure reduction. That means narrowing who can browse high-risk content, increasing update enforcement, and reducing the chance that a successful browser compromise can be used to reach sensitive data or credentials.

In practice, that can include temporarily tightening browser policy, restricting untrusted browsing on unmanaged devices, and checking whether remote work or admin workflows rely on the affected browser family. The objective is to reduce the blast radius while the patch path is being completed, not to assume that user caution will be enough.

Postponed patching also increases the value of compromise hunting. If a user device may have been exposed before remediation, review browser crash history, security telemetry, suspicious downloads, unexpected profile changes and any signs of follow-on authentication abuse. Where a device handled sensitive sessions, consider whether session revocation or credential rotation is warranted as a precaution.

For a vulnerability that is already known to be exploited, the right operating model is the one used for emergency vulnerability handling: confirm scope, prioritise the exposed estate, remediate quickly, then verify that the affected devices actually received the fix. The CVE Program record is useful for exact identification, while the vendor advisory remains the source for Apple build-specific remediation guidance.

Risk and Threat Considerations

The main risk is that a browser engine exploit collapses the normal safety boundary between web content and the endpoint. Because the flaw is triggered through routine browsing, exposure can be broad, and successful exploitation can occur before users or defenders notice anything unusual.

Failure mechanism: Malicious web content reaches the WebKit processing path, the vulnerability triggers code execution, and the attacker gains an initial foothold on the device without needing prior access.

Impact: The compromise can lead to endpoint control, credential theft, session theft, or secondary malware deployment, especially if the affected device is used for administrative or high-trust work.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	CVE exploitation requires rapid identification and remediation of exposed Apple devices.
Recommendation — Prioritise KEV-listed flaws in your vulnerability workflow and verify remediation on affected assets.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The issue demands timely patching and verification after active exploitation is confirmed.
Recommendation — Apply flaw-remediation processes that accelerate patching and validate deployment on in-scope endpoints.
OWASP ASVS	V12 — Cryptography	Browser code execution can expose sensitive sessions and transport-dependent data handling around web content.
Recommendation — Review browser-facing controls that reduce exposure of sensitive data during and after compromise.
NIST CSF 2.0	DE.CM-01 — The network is monitored to detect potential cybersecurity events.	Exploited browser flaws warrant monitoring for compromise indicators and follow-on activity.
Recommendation — Increase telemetry and alerting for suspicious endpoint and browser activity after exposure.
MITRE ATT&CK	T1189 — Drive-by Compromise	Malicious web content is the classic initial-access path for browser engine exploitation.
Recommendation — Hunt for drive-by delivery and browser-triggered initial access in your detection pipeline.

Practitioner Guidance

What to prioritise: Treat KEV-listed browser engine flaws as exposure-reduction events, not as ordinary backlog items. Start with internet-facing and high-trust user devices, because they deliver the fastest risk reduction per patch applied.

What to verify: Confirm that the affected Apple platforms are actually updated, not merely eligible for update. In mixed-device fleets, verify compliance by telemetry or device management evidence rather than relying on user reports.

Decision rule: If a device can browse untrusted content and also holds privileged access, sensitive tokens or access to internal systems, escalate it for immediate remediation and post-exposure review.

Practitioner takeaway: With an exploited browser engine flaw, the practical question is how quickly you can shrink exposure and validate remediation, because waiting for evidence of compromise usually means you have already lost the timing advantage.