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

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.

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.

Related resources from NHI Mgmt Group

• Is CVE-2025-43300 (Apple iOS, iPadOS, and macOS Out-of-Bounds Write) being exploited in the wild?
• Is CVE-2021-30900 (Apple iOS, iPadOS, and macOS Out-of-Bounds Write) being exploited in the wild?
• How do you patch or mitigate CVE-2022-32894 (Apple iOS and macOS Out-of-Bounds Write)?
• Is CVE-2023-28206 (Apple iOS, iPadOS, and macOS IOSurfaceAccelerator Out-of-Bounds Write) being exploited in the wild?