Is CVE-2023-28204 (Apple Multiple Products WebKit Out-of-Bounds Read) being exploited in the wild?

How to read “exploited in the wild” for CVE-2023-28204

CISA’s KEV listing is the practical signal that matters here: it means the vulnerability was not just theoretically dangerous, but had credible evidence of active abuse. For this CVE, that should shift the question from “is it real?” to “where is this Apple WebKit exposure still reachable through browsers, embedded web views, or devices that have not yet been fully updated?”

Because the flaw is in WebKit, the exposure surface is broader than Safari alone. Any Apple platform or app path that renders malicious web content can become part of the attack path, which is why browser hardening and timely device updates matter even when users do not think of themselves as browsing suspicious sites. Enterprise Browser and Browser Security Guide

This is also a good example of why “exploited in the wild” should be treated as an operational priority, not just an intelligence label. Once a weakness appears in the KEV catalogue, defenders should assume exploit attempts are plausible across ordinary web traffic, drive-by content, and any workflow that opens untrusted pages or rich content in a browser context. CISA Known Exploited Vulnerabilities Catalog

What the WebKit weakness means operationally

An out-of-bounds read in a browser engine is especially concerning because the immediate outcome is often information disclosure rather than obvious crash behavior. In practice, that can still be enough for an attacker to learn memory contents, recover sensitive state, or combine the leak with a second-stage exploit path. CVE Program

That operational reality is why browser-engine bugs are often treated as high-value exploitation primitives. They are widely exposed, reachable through routine user activity, and difficult to contain once malicious content is rendered. When the same engine is reused across multiple Apple products, a single weakness can create a large and heterogeneous exposure base. The broader pattern is covered in Zero-Day and Exploited Vulnerabilities Guide.

For defenders, the key question is not only whether a device runs Safari, but whether it can process attacker-controlled web content at all. That includes managed endpoints, mobile devices, and environments where web content is displayed inside an application wrapper or embedded browser view.

How to prioritize response when patching or validation is delayed

When a vulnerability is already in KEV, delaying action requires a clear exception rather than an informal wait for the next maintenance window. The practical priority is to confirm exposure, accelerate remediation, and reduce reachability from untrusted web content wherever immediate updating is not yet possible. NIST National Vulnerability Database

If patching must wait, the most useful short-term controls are exposure reduction and monitoring, not passive acceptance. That usually means tightening browser handling of untrusted content, limiting use of unmanaged devices for sensitive browsing, and reviewing whether vulnerable Apple platforms are allowed to access higher-value services during the exposure window.

It is also worth checking whether the issue could have been abused before remediation. For web-engine flaws, investigation should focus on unusual browser activity, suspicious redirects, unexpected downloads, and signs that a device was used as an initial foothold rather than looking only for a visible crash. Vulnerability Management Guide

Risk and Threat Considerations

Active exploitation changes the risk profile from theoretical memory disclosure to likely attacker interest. With browser-engine flaws, the attacker objective is often to extract sensitive information or chain the bug into a broader compromise path, especially on devices that routinely open external content.

Failure mechanism: The browser processes maliciously crafted web content and reads memory outside the intended boundary, which can disclose data that should have remained inaccessible to the rendering process.

Impact: Sensitive information may be exposed on affected Apple devices, and that disclosure can support follow-on exploitation, account compromise, or broader intrusion depending on what the attacker recovers.

Practitioner Guidance

What to verify: Confirm which Apple device classes and browser paths are actually in use, including managed endpoints, mobile fleets, and any application that embeds WebKit. Exposure often persists in places teams overlook because they track “browser version” but not “where web content can execute.”

Decision rule: If the device can process untrusted web content and has not been remediated, treat it as priority exposure even if you have not seen signs of compromise. If patching is delayed, compensate by reducing access to sensitive workflows and reviewing recent browsing activity on high-value endpoints.

What to prioritize: Focus first on systems that can reach privileged data, administrative portals, or sensitive internal services. The highest-value question is not whether a device is vulnerable in isolation, but what a successful memory disclosure would allow an attacker to reach next.

Practitioner takeaway: For KEV-listed browser flaws, exploitation status should drive urgency, and the right response is to combine rapid remediation with exposure reduction and compromise review rather than waiting for visible abuse.

Related resources from NHI Mgmt Group

• Is CVE-2023-42916 (Apple Multiple Products WebKit Out-of-Bounds Read) being exploited in the wild?
• How do you patch or mitigate CVE-2023-28204 (Apple Multiple Products WebKit Out-of-Bounds Read)?
• CVE-2023-28204 (Apple Multiple Products WebKit Out-of-Bounds Read)
• Is CVE-2025-24201 (Apple Multiple Products WebKit Out-of-Bounds Write) being exploited in the wild?