Yes. CISA added CVE-2023-32373 to its Known Exploited Vulnerabilities catalogue on 22 May 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, tvOS, watchOS, and Safari WebKit contain a use-after-free vulnerability that leads to code execution when processing maliciously crafted web content.
How CISA’s KEV Listing Changes the Answer
CISA’s inclusion of a CVE in the Known Exploited Vulnerabilities catalogue is the practical signal that matters here: treat the issue as active, not hypothetical. For Apple WebKit exploitation, the operational question is no longer whether the weakness is real, but whether your fleet still exposes the vulnerable browser or embedded WebKit surface through a product, app, or supported operating system.
That changes prioritisation. When a browser engine flaw is already being exploited, patch timing, exposure scope, and user reach matter more than abstract severity discussions. Organisations should confirm where WebKit is present, where browsers are allowed to auto-update, and which managed endpoints can still delay remediation because of test cycles or software constraints.
Because the issue affects multiple Apple platforms and browser surfaces, a browser-centric review is useful even when the endpoint estate looks well managed. Enterprise Browser and Browser Security Guide is a natural companion here because it helps teams think about browser hardening, extension control, isolation, and credential exposure together rather than as separate problems.
What Exploitation of WebKit Usually Means in Practice
A use-after-free in a browser engine is dangerous because the engine parses untrusted web content at scale, often with broad user reach and frequent exposure. In practical terms, exploitation can begin with a malicious page, ad, embedded content, or redirected link, then progress into code execution inside the browser process or an adjacent component, depending on the exploit chain.
The security consequence is often not limited to the browser itself. A successful exploit can become the first stage in a broader compromise chain, especially if the browser has access to saved sessions, enterprise apps, synced data, or local tokens. That is why exploited browser vulnerabilities are treated as endpoint-risk problems, not just software-quality issues.
For remediation planning, teams should treat the browser engine and the operating system as a combined attack surface, not as isolated products. Zero-Day and Exploited Vulnerabilities Guide is directly relevant because it focuses on KEV triage, emergency mitigation, and post-patch hunting for vulnerabilities that are already being used in the wild.
What to Do When Patching Cannot Happen Immediately
If remediation has to wait, reduce exposure quickly rather than trying to compensate with awareness training or passive monitoring alone. The practical levers are browser isolation, tighter web access controls, accelerated update enforcement, and temporary restriction of high-risk browsing paths on devices that cannot move yet. The goal is to reduce the number of opportunities for malicious content to reach the vulnerable code path.
It is also worth checking whether any endpoints have drifted from standard patch channels, especially shared devices, privileged user devices, and systems with delayed operating system approval. The CISA KEV listing should be used as a trigger to verify exposure, not just to open a ticket. If the vulnerable product is present, assume exploitation pressure is real until the fleet has been confirmed remediated.
For prioritisation discipline, use a vulnerability management process that explicitly distinguishes exposure from theoretical severity. Vulnerability Management Guide is useful here because it ties KEV status, verification, prioritisation, exceptions, and remediation evidence into one operational workflow.
Risk and Threat Considerations
Browser-engine vulnerabilities are attractive because they sit on a high-frequency, internet-facing path and can be triggered with little user friction. When the flaw is already in active exploitation, the main risk is not just compromise of one workstation, but the possibility of session theft, lateral follow-on activity, or footholds on managed devices that users trust for business access.
Failure mechanism: Malicious web content reaches the WebKit parser, triggers memory corruption through the use-after-free condition, and gives the attacker a code execution path before normal user awareness or endpoint containment can intervene.
Impact: The result can be browser compromise, credential or session exposure, and a broader endpoint incident if the attacker uses the initial foothold to persist, pivot, or harvest additional access material.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | KEV-listed exploitation requires risk-based prioritisation and exception handling. |
| Recommendation — Prioritise KEV-listed browser exploits ahead of routine patch work. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Active exploitation makes exposure verification and remediation workflow central. |
| Recommendation — Track and remediate the Apple WebKit exposure through continuous vulnerability management. | ||
| OWASP ASVS | V12 — Cryptography | Browser exploit chains can expose sessions and secure communications handled by web-facing components. |
| Recommendation — Review browser-facing session and transport assumptions that could be abused after compromise. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | A KEV-listed exploited CVE demands prompt flaw remediation and exposure verification. |
| RA-5 — Vulnerability Monitoring and Scanning | You need ongoing identification of affected Apple endpoints and delayed remediation cases. | |
| Recommendation — Remediate the WebKit flaw promptly and document confirmation of fleet-wide fix status. Scan for exposed Apple systems and track remediation status until closure. | ||
Practitioner Guidance
What to verify: Confirm whether Apple-managed updates are actually reaching all supported iOS, iPadOS, macOS, tvOS, watchOS, and Safari installations in scope, including devices that are off-network, slow to check in, or excluded from normal patch rings.
Decision rule: If a device can browse the web and has not been confirmed patched after KEV publication, treat it as an active exposure until proven otherwise, and prioritise it ahead of routine maintenance work.
Common mistake: Assuming the browser fix alone is enough while ignoring endpoints that cache sessions, store passwords, or have privileged access to SaaS and internal portals.
Practitioner takeaway: For KEV-listed browser exploits, the right response is exposure-driven remediation, then a quick check for signs of session or endpoint abuse, because active exploitation changes the risk from “patch soon” to “verify and close now.”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org