Is CVE-2022-22587 (Apple Memory Corruption) being exploited in the wild?

Yes. CISA added CVE-2022-22587 to its Known Exploited Vulnerabilities catalogue on 28 January 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Apple IOMobileFrameBuffer contains a memory corruption vulnerability which can allow a malicious application to execute arbitrary code with kernel privileges.

Yes. The key signal is not just that Apple reported a kernel-level memory corruption issue, but that CISA placed it in the KEV catalogue, which means there is reliable evidence of exploitation in the wild. For response teams, that moves the question from theoretical exposure to active prioritisation, especially on managed mobile fleets and any device that could expose privileged code execution.

For mobile fleets, the practical question is whether vulnerable devices are still reachable and whether they are enrolled, supervised, or otherwise managed in a way that lets you enforce remediation quickly. A kernel-memory issue can undermine the trust boundary of the device itself, so exposure assessment should include inventory accuracy, patch state, and whether devices are in a state where remote management can still act on them.

When patching or upgrades cannot happen immediately, treat the device as higher risk for compromise containment rather than as merely “unpatched.” That means reducing the attack surface around app installation, limiting exposure to untrusted content and apps, and tightening monitoring for unusual device behaviour, especially where the device is used for email, messaging, or access to business systems.

Why KEV Listing Matters More Than the CVE Label

A KEV entry is a prioritisation signal, not just a catalogued weakness. It tells defenders that the issue has crossed the threshold from advisory-only concern to confirmed attacker interest, so patch sequencing, exception handling, and exposure review should be accelerated. The exact exploit path can vary, but the operational conclusion is the same: you should assume the vulnerability has already been weaponised somewhere.

For this type of issue, the most important distinction is between “known vulnerable” and “known exposed.” Devices that are powered off, retired, or isolated present a different risk than active, internet-reachable, or routinely used endpoints. That is why KEV-driven response should begin with scope validation, not with a generic patch broadcast.

For mobile-specific hardening and fleet response patterns, Mobile Device Security Guide is the right place to anchor the operational controls that matter most here.

What This Means for Exposure, Containment, and Recovery

The vulnerability described here is a memory corruption flaw in a kernel-adjacent component, which is serious because successful exploitation can cross from application context into kernel privileges. That changes the response posture: you are not only looking for app-level abuse, but for signs that device integrity, security boundaries, and trust decisions on the endpoint may already be affected.

In practice, responders should think in three layers: first, whether the device is vulnerable; second, whether exploitation may have occurred; and third, whether the device can still be trusted for sensitive work. If any of those answers is uncertain, it is reasonable to treat the device as suspect until patching and validation are complete.

The most useful supporting reference for this workflow is Zero-Day and Exploited Vulnerabilities Guide, which aligns with the need for emergency mitigation and compromise assessment when exploitation is already confirmed.

How to Prioritise Response Without Overreacting

Not every exploited CVE requires the same emergency path, but a KEV-listed kernel issue should be handled ahead of routine backlog items. The right triage lens is: reachable assets first, highest-value users first, and devices with business access first. If patching will be delayed, isolate the device’s access paths before you spend time debating the likelihood of further exploitation.

Also check whether the vulnerable devices are part of a broader mobile access pattern, because the real risk may be the accounts and sessions those devices carry, not only the device itself. If the device is used for privileged workflows, reset expectations about trust until the patch is in place and the fleet has been revalidated.

For prioritisation discipline, Vulnerability Management Guide provides the most relevant structure for scope, prioritisation, exceptions, and verification.

Risk and Threat Considerations

This kind of vulnerability is attractive to attackers because it offers a path from ordinary application execution to kernel-level compromise. Once that boundary is crossed, the attacker may be able to evade normal app controls, persist longer, or gain enough control to access data and sessions that were not meant to be reachable from the original app context.

Failure mechanism: Memory corruption in a privileged component can be turned into code execution with elevated privileges, especially when the victim device remains reachable and unpatched.

Impact: The result can be full device compromise, loss of trust in the endpoint, and downstream access to user data, enterprise services, or authenticated sessions that depended on that device’s integrity.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	Explained KEV-driven prioritisation for an actively exploited vulnerability.
Recommendation — Prioritise remediation of KEV-listed assets ahead of routine vulnerability backlog items.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Supports exposure validation and remediation for a known exploited CVE.
	SI-2 — Flaw Remediation	Directly supports patching or mitigation when a flaw is being exploited in the wild.
	IR-4 — Incident Handling	Supports compromise assessment when exploitation is already confirmed.
Recommendation — Verify asset exposure and track remediation status for the vulnerable devices. Apply the fix or mitigation as soon as operationally possible. Investigate whether impacted devices show signs of compromise before returning them to service.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Fits active exploitation triage, scanning, and timely remediation of vulnerable endpoints.
Recommendation — Accelerate identification and remediation of vulnerable endpoints flagged as actively exploited.

Practitioner Guidance

What to prioritise: Validate whether the affected devices are still in service, then rank them by business criticality and access exposure. Devices used for corporate email, admin tasks, or sensitive apps deserve immediate attention because their compromise has more than just a local impact.

What to verify: Confirm patch status from device inventory, not from user reports, and verify whether any device showing suspicious behaviour should be removed from service before remediation. If you cannot prove device integrity after suspected exploitation, treat the device as untrusted until it is rebuilt or otherwise validated.

Practitioner takeaway: KEV listing should change your response posture immediately: confirm exposure, patch or isolate fast, and assume the device may have been used as a stepping stone even if you have not yet found clear evidence of abuse.