How do you patch or mitigate CVE-2023-28204 (Apple Multiple Products WebKit Out-of-Bounds Read)?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

CISA's required action for CVE-2023-28204 is to apply updates per vendor instructions. In practice, find every instance of Apple Multiple Products in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What CVE-2023-28204 means for patching priority

This is a browser-engine vulnerability, so the first practical question is not whether the flaw exists in theory, but where Apple WebKit is present in your estate and whether those systems are reachable from untrusted content. Browser engine issues often become priority items because they sit at the edge of normal user activity, and exploitation can be triggered simply by viewing content.

That is why the most reliable response is to treat every affected Apple platform as a patch candidate and to verify exposure by device inventory, browser usage, and OS update posture. The vendor fix is the primary remediation path, while temporary exposure reduction is the fallback when immediate updating is not possible.

How to reduce exposure before and during remediation

Start by identifying every Apple product instance that can render WebKit content, then confirm whether it is internet-facing, used for browsing hostile content, or allowed to open untrusted links and pages. When the update cannot be applied immediately, the safest short-term move is to remove or sharply limit internet exposure, because that reduces the chance of a successful trigger while the vulnerable component remains present.

If you need a stopgap, prefer controls that shrink attack surface rather than controls that merely hope the flaw will not be reached. That means tightening access paths, limiting browsing exposure, and taking the product out of service where the risk cannot be bounded. For browser-adjacent weaknesses, keeping the host online but “carefully used” is usually weaker than isolating it or removing it from active duty until the update lands.

For practical patch operations, the update itself should be handled as an emergency change on affected Apple endpoints, with verification after installation. The goal is not only to deploy the fix, but also to prove that the affected software was actually updated across the estate and that no lagging devices remain exposed.

What to check after patching is complete

Once remediation is done, review logs and telemetry for signs that the vulnerability may have been used before the fix was applied. That includes unusual browser activity, unexpected crashes, suspicious page loads, or downstream indicators of compromise on the affected device.

Because the issue was exploited in the wild, post-patch validation should assume possible prior compromise until the evidence says otherwise. If you find indications that the device was used as an initial access point, widen the review to account for session abuse, credential exposure, and any follow-on activity from the affected user account or host.

Risk and Threat Considerations

Out-of-bounds read flaws in browser engines are risky because they can be reached through ordinary content consumption and may expose sensitive memory or support broader exploitation chains. When the flaw is already being used in the wild, the main concern is not just crash or instability, but the possibility that a normal browsing action became the entry point for compromise.

Failure mechanism: A malicious page or content path can trigger the vulnerable WebKit code path before the user has any obvious warning, creating a chance for memory disclosure or further exploitation.

Impact: Systems left unpatched can become reliable footholds for intrusion, especially when the vulnerable browser engine is present on devices that regularly access external content.

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	CVE patching and exposure review are core vulnerability management tasks.
Recommendation — Prioritise, patch, and verify exposed assets through a continuous vulnerability management process.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This CVE requires vendor updates and verification that the flaw is remediated.
	AU-6 — Audit Review, Analysis, and Reporting	Post-patch log review is needed to look for earlier exploitation.
Recommendation — Apply timely flaw remediation and confirm the update is deployed across all affected systems. Review and correlate logs to identify possible pre-remediation exploitation.
NIST CSF 2.0	PR.IP-12 — Vulnerability Management Plan	The response follows a planned process for finding, prioritising, and remediating known vulnerabilities.
Recommendation — Use a vulnerability management plan to drive emergency patching and exception handling.
OWASP ASVS	V13 — Configuration	Reducing internet exposure and limiting risky deployment settings are configuration controls.
Recommendation — Harden deployment settings to reduce exposure when immediate patching is delayed.

Practitioner Guidance

What to prioritise: Patch every exposed Apple instance first, then handle the devices that are most likely to browse untrusted content or be used for sensitive work. If you must stage remediation, do not let “low business criticality” override exposure, because a rarely used but internet-reachable endpoint can still be the easiest compromise path.

What to verify: Confirm that the vendor update really landed on every in-scope device, not just that the change was approved. After that, validate logs for pre-patch indicators and decide whether any endpoint needs deeper incident response rather than simple remediation.

Practitioner takeaway: For an exploited browser-engine flaw, the right sequence is exposure reduction, verified vendor updating, then compromise review, because patching alone does not answer whether the device was already used as an access point.

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