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

Yes. CISA added CVE-2022-32894 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 an application to execute code with kernel privileges.

What “being exploited in the wild” means for this CVE

CVE-2022-32894 is not just a published weakness, it is a vulnerability CISA judged to be actively exploited. For practitioners, that changes the question from “is this real?” to “is any exposed Apple iOS or macOS estate still vulnerable, and can we prove remediation happened?” The practical response starts with asset inventory, exposure confirmation, and prioritised remediation.

Apple’s advisory and the CISA KEV entry should be treated as the authoritative sources for version status and required action. The KEV listing is especially important because it is a minimum bar for urgent handling, not a broad risk score. If you are tracking mobile or endpoint exposure, the relevant operational issue is whether vulnerable devices can still receive updates and whether any lagging fleet segments remain unmanaged.

Where the subject overlaps mobile fleet control, use the Mobile Device Security Guide to align the vulnerability response with device enrolment, MDM coverage, and compliance enforcement. For a CVE like this, the difference between a contained issue and a lingering exposure often comes down to whether the organisation actually has visibility into supervised iOS and managed macOS devices.

Why kernel-level exploitation raises the stakes

The direct technical concern is not only code execution, but execution with kernel privileges. That means a successful exploit can move beyond a normal application sandbox and reach much higher-impact system functions. On Apple platforms, that materially changes the blast radius because it can undermine protections that depend on the operating system trust boundary remaining intact.

Because the vulnerability is an out-of-bounds write, the failure mode is memory corruption rather than simple logic abuse. That makes it attractive for attackers seeking reliable privilege gain or deeper system control. For defenders, the important implication is that exploitation may not present as a noisy crash or obvious malware family, so patch urgency should not depend on seeing strong secondary indicators first.

If you need a broader remediation lens, the Zero-Day and Exploited Vulnerabilities Guide provides a useful model for time-sensitive triage, emergency mitigation, and post-patch validation. That framing fits this CVE because active exploitation means exposure windows matter more than theoretical severity alone.

What to do when patching is delayed or uncertain

When patching cannot happen immediately, focus on reducing the number of devices that can be reached and on proving whether the vulnerable condition still exists. For managed fleets, that means identifying unmanaged or out-of-policy devices, checking update posture, and tightening any administrative pathways that let a device remain connected while unpatched. If the device is critical, isolate it until it can be remediated.

For incident response, do not stop at patch deployment. Review whether the vulnerable device was exposed during the active exploitation window, whether unusual reboots, configuration changes, or unexplained user reports occurred, and whether any adjacent accounts or sessions should be revalidated. In practice, the main investigation question is whether the exploit was used as a one-time foothold or as a step toward persistence.

Where version and prioritisation decisions need structure, the Vulnerability Management Guide is the most relevant internal reference for KEV-driven prioritisation, exception handling, and verification. CISA’s KEV catalogue and the vendor advisory remain the primary sources for the exact action required.

Risk and Threat Considerations

Active exploitation changes the risk profile from preventive maintenance to exposure management. The main threat is that an attacker may gain high-privilege execution on a device before defenders have closed the window, especially if the endpoint is internet-facing, poorly managed, or slow to update.

Failure mechanism: An out-of-bounds write can corrupt memory in a way that enables code execution with kernel privileges, which can defeat the normal isolation model and give an attacker a stronger foothold than a standard app compromise.

Impact: Successful exploitation can lead to device compromise, tampering with security controls, and a higher chance of credential, session, or data exposure on the affected endpoint.

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 governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes rapid vulnerability prioritisation and remediation central.
Recommendation — Prioritise and remediate KEV-listed Apple endpoints before lower-risk backlog items.
NIST CSF 2.0	ID.RA-01 — Vulnerabilities are identified and documented	This CVE page is about identifying a known exploited vulnerability and its exposure.
	PR.IP-12 — A vulnerability management plan is developed and implemented	The answer focuses on KEV-driven remediation, verification, and exception handling.
Recommendation — Track the vulnerable Apple estate and document exposed devices for urgent action. Use a KEV-driven vulnerability process to verify and close affected Apple devices.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	A known exploited Apple flaw requires timely remediation and verification.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation and post-patch validation depend on vulnerability monitoring.
Recommendation — Apply flaw remediation discipline and confirm patched status across the fleet. Scan and validate Apple endpoint exposure before closing the remediation case.

Practitioner Guidance

What to verify: Confirm whether every iOS and macOS device in scope is on a supported, up-to-date release and whether any unmanaged endpoints can still connect to corporate services. Treat “we pushed the update” as insufficient until you can verify install state, not just approval state.

Decision rule: If a device cannot be verified as patched and is still reachable, treat it as exposed and prioritise removal from service, isolation, or accelerated remediation over deeper forensic work. If you suspect compromise, collect evidence before rebooting or reimaging because kernel-level exploitation can destroy useful artefacts.

Practitioner takeaway: For KEV-listed Apple vulnerabilities, the operational priority is not abstract severity ranking, it is proving whether exposure still exists and whether any device in the fleet could already have been used as an entry point.