Is CVE-2023-28205 (Apple Multiple Products WebKit Use-After-Free) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Cyber Security

Yes. CISA added CVE-2023-28205 to its Known Exploited Vulnerabilities catalogue on 10 April 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 a use-after-free vulnerability that leads to code execution when processing maliciously crafted web content.

How to interpret “being exploited in the wild” for this CVE

For a vulnerability question like this, the practical meaning is simple: do not treat it as a theoretical weakness. CISA’s KEV listing tells you there is sufficient evidence of active exploitation to justify urgent action, so the question is less about whether the flaw can be abused and more about whether exposed Apple and WebKit-based systems still need immediate attention.

Because the direct answer already identifies the affected Apple platforms and the use-after-free class, the main operational task is to confirm whether those platforms are present anywhere in your fleet, then map them to exposed browsers, managed endpoints, and any embedded WebKit consumers that may not be obvious in inventory.

When the vulnerable component is a browser engine, exposure often extends beyond the primary browser app itself. Web content rendering can occur inside other apps, managed devices, or enterprise browser environments, so the inventory question should be broader than “do we use Safari?”

What makes WebKit exploitation operationally urgent

Use-after-free flaws are especially dangerous because they can become code execution bugs when malicious content reaches the vulnerable parser or renderer. In practice, that means a single crafted page, ad, document preview, or embedded web view can become the delivery vehicle for initial compromise if the platform remains unpatched.

For defenders, the important point is that exploitation does not require a user to perform an obviously suspicious action. A normal browsing or content-rendering workflow can be enough, which is why browser-engine issues often sit at the boundary between endpoint security, browser hardening, and vulnerability response.

The strongest response is to assume that any unpatched exposed system may already have been targeted, then verify whether the vulnerable device has been updated through the vendor’s advisory and whether the host shows signs of post-exploitation activity such as suspicious child processes, unusual downloads, browser crashes preceding compromise, or new persistence artifacts.

What to do if patching is delayed

If patching cannot happen immediately, reduce exposure by constraining where the vulnerable browser engine can reach untrusted content, tightening browser policy, and limiting the set of users or devices that can still browse externally while the fix is pending. If the affected platform is business-critical, isolate it from higher-risk browsing tasks rather than leaving it fully exposed.

Use this delay window to assess blast radius, because a browser-engine exploit can be a starting point for credential theft, session theft, or follow-on payload delivery. If the vulnerable device handles corporate authentication, email, or privileged workflows, treat it as higher priority than a generic endpoint with minimal access.

Where compromise is plausible, check for indicators of earlier access before the patch lands. That means examining browser histories, downloads, crash logs, outbound connections, newly created launch items, and any suspicious security prompts or authorization events that occurred around the relevant time window.

Standards & Framework Alignment

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

CIS Controls v8, NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited CVEs require rapid identification and remediation prioritization.
Recommendation — Prioritize and remediate KEV-listed vulnerabilities across all exposed Apple endpoints.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This CVE response depends on identifying exposed assets and tracking remediation status.
	SI-2 — Flaw Remediation	A confirmed exploited software flaw requires timely correction or mitigation.
Recommendation — Scan for affected Apple systems and verify remediation completion. Apply the vendor fix or compensating mitigation as soon as feasible.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	The answer hinges on confirming whether vulnerable Apple products are present and exposed.
	RS.MA-01 — Incident Mitigation	Active exploitation calls for immediate containment and remediation actions.
Recommendation — Inventory Apple devices and browser surfaces that may expose WebKit. Contain exposed systems and investigate possible compromise while patching.
OWASP ASVS	V12 — Secure Communication	Browser-engine exploitation is often initiated through malicious web content and unsafe content handling.
Recommendation — Harden browser and web-content handling controls that reduce malicious content exposure.

Practitioner Guidance

What to prioritise: Put exposed Apple endpoints and any WebKit-reliant managed browser surfaces at the front of the queue, especially if they are used for admin work, email, or access to sensitive SaaS apps. A browser-engine CVE with active exploitation should be handled as a fleet exposure problem, not just an end-user patch task.

What to verify: Confirm the actual OS and browser-engine versions in use, then validate that the remediation reached every device class that can render WebKit content. A common mistake is to check only the flagship browser while missing embedded web views, unmanaged laptops, or delayed-updates devices.

Decision rule: If a system is both exposed and business-critical, prioritize containment and compromise assessment alongside patching, because the question is not only whether the flaw is fixable, but whether the endpoint may already have been used as an entry point.

Practitioner takeaway: With a KEV-listed browser-engine flaw, speed matters, but so does scope, assume every reachable WebKit surface is part of the exposure set until you can prove otherwise.

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.

NHIMG Editorial Note
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