Is CVE-2022-32893 (Apple iOS and macOS Out-of-Bounds Write) being exploited in the wild?

Yes. CISA added CVE-2022-32893 to its Known Exploited Vulnerabilities catalogue on 18 August 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Apple iOS and macOS contain an out-of-bounds write vulnerability that could allow for remote code execution when processing malicious crafted web content.

What Exploited in the Wild Means for CVE-2022-32893

CISA’s KEV listing is the key operational signal here, because it means the vulnerability was considered actively exploited, not just theoretically dangerous. For teams running Apple devices, that changes the question from “should we care?” to “where are we exposed, and how fast can we close the window?” A likely parallel check is whether the affected devices are covered by your Mobile Device Security Guide controls for inventory, enrollment, and policy enforcement.

The practical meaning of an out-of-bounds write in browser-facing content processing is that malicious web content can become an entry point without user intent beyond loading or previewing content. That is why exploitability matters more than the label alone: if the code path is reachable through normal browsing or embedded rendering, exposure can exist anywhere the platform processes untrusted web content. For broader vulnerability triage, the Zero-Day and Exploited Vulnerabilities Guide is the right lens for prioritising active exploitation over ordinary backlog handling.

When a vulnerability is already in KEV, the response standard is no longer ordinary patch cadence. Teams should treat it as an active exposure issue, not a routine software hygiene task, and should use vendor guidance plus the KEV record to verify remediation requirements for the exact device and OS lines in scope. If you need a general process model for handling a live vulnerability, the Vulnerability Management Guide gives the operational context for scope, prioritisation, verification, and exception handling.

Risk and Threat Considerations

Actively exploited mobile and desktop flaws create two overlapping risks: direct device compromise and downstream exposure of data, sessions, and enterprise access that sit behind the device. On iOS and macOS, the concern is not only code execution on the endpoint, but also what an attacker can reach after gaining that foothold, especially if the device holds corporate email, browser sessions, or management trust.

Failure mechanism: A malicious web page or embedded content triggers the out-of-bounds write during content processing, which can let an attacker execute code in the context of the affected process and then attempt follow-on actions on the device.

Impact: The practical impact ranges from single-device compromise to credential theft, session abuse, data access, and broader enterprise pivoting if the endpoint has trusted access to business services.

What Practitioners Should Do First

What to verify: Confirm which Apple iOS and macOS devices are exposed, then verify whether your patching process has actually removed the vulnerable build from the fleet rather than only scheduled it. For exploited issues, verification matters as much as deployment because a partially remediated fleet still leaves an attack path open.

Decision rule: If the device can reach the internet or process untrusted web content, treat it as high priority even if it is not a privileged workstation. If patching must wait, isolate the device from sensitive services and reduce what it can access until remediation is complete.

What to measure: Track exposure by asset count, remediation age, and the percentage of at-risk devices that have been validated after update. For exploited vulnerabilities, the useful metric is not just patch availability, but how quickly confirmed exposure is shrinking.

Practitioner takeaway: Once a flaw is in KEV, the correct response is exposure management plus verification, not debate over theoretical severity, because the attacker already has evidence of a working path.

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 CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes timely identification and remediation central to the issue.
Recommendation — Prioritise, verify, and track remediation of KEV-listed exposures on all in-scope Apple devices.
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and documented	The question is about whether an actively exploited vulnerability affects the environment.
	PR.IP-12 — Vulnerability management program is implemented	An exploited CVE requires governed prioritisation, remediation, and verification.
Recommendation — Document exposed Apple assets and update vulnerability records for the affected CVE. Apply expedited remediation and validation steps for KEV-listed Apple vulnerabilities.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Known exploitation makes flaw remediation and timely update handling directly applicable.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation and post-fix verification depend on ongoing vulnerability monitoring.
Recommendation — Remediate the Apple flaw quickly and confirm the vulnerable version is removed from service. Scan Apple endpoints, confirm exposure, and verify remediation after update.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	The issue is a live technical vulnerability requiring managed assessment and treatment.
Recommendation — Track, prioritise, and remediate the exploited Apple vulnerability under your vulnerability process.

Practitioner Guidance

What to prioritise: Start with externally reachable and business-critical Apple devices, then move to any endpoint that regularly handles email, browser-based administration, or privileged workflows. Those systems have the highest chance of turning a local compromise into an enterprise incident.

Escalation / exception: If patching is delayed, treat the exception as time-bounded and compensating-control driven, not open-ended. Restrict exposure, monitor for suspicious browser or process activity, and review whether the device should be allowed to retain access to sensitive resources while unpatched.

What good looks like: You can say which devices were exposed, which were updated, which were verified, and whether any signs of compromise existed before remediation. That evidence trail is what separates a real response from a best-effort patch.

Practitioner takeaway: For a KEV-listed Apple flaw, success is measured by verified removal of exposure and post-fix confidence, not by the existence of a patch alone.