Is CVE-2022-32917 (Apple iOS, iPadOS, and macOS Remote Code Execution) being exploited in the wild?

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

Yes. CISA added CVE-2022-32917 to its Known Exploited Vulnerabilities catalogue on 14 September 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Apple kernel, which is included in iOS, iPadOS, and macOS, contains an unspecified vulnerability where an application may be able to execute code with kernel privileges.

How to tell whether CVE-2022-32917 is being exploited in the wild

The practical test is not whether the bug exists, but whether there is reliable evidence of active exploitation. For this CVE, CISA’s KEV listing is the strongest public signal you can use in triage. That should shift the question from “is it real?” to “is any Apple device in my estate still exposed, and have I already seen suspicious kernel-level behavior?”

Because the issue affects the kernel path in iOS, iPadOS, and macOS, exploitation can have a wider blast radius than an ordinary app crash or browser bug. A successful exploit may be used for high-privilege execution, so it is worth checking whether any devices were running vulnerable software before you focus on attribution or motive. For broader prioritisation and remediation workflow, see the Vulnerability Management Guide.

What exposure to check and what to verify first

Start with asset scope, not rumor tracking. Confirm which Apple endpoints are in service, whether they were reachable during the exposure window, and whether any of them match the product family named in the direct answer. If you manage fleets, this is the moment to separate fully managed devices from unmanaged or personal devices, because visibility gaps are often where exploited devices hide.

Then verify whether any endpoint telemetry, crash logs, EDR events, or MDM alerts show unusual privilege escalation, unexplained process behavior, or post-exploitation tooling. With kernel-level exploitation, the most useful evidence is often indirect: anomalous child processes, persistence artifacts, configuration tampering, or account activity that does not fit the user’s normal pattern. If you need a structured mobile estate view, the Mobile Device Security Guide helps frame what should be visible across enrollment, policy, and device control.

What to do when patching or remediation must wait

If immediate remediation is not possible, treat the affected devices as potentially targeted systems and reduce their exposure surface. That means removing unnecessary network reachability, limiting high-risk access paths, and increasing monitoring on any device that still needs to remain in service. For a kernel RCE, waiting without compensating controls is usually a bad trade unless business continuity truly requires it.

Where the device may have been reachable before mitigation, the safest next step is to assume compromise may have occurred and preserve evidence before performing disruptive cleanup. That includes relevant logs, device inventory state, and any suspicious artifacts that could support later investigation. For vulnerability prioritisation and exception handling in an exploited-vulnerability scenario, the Zero-Day and Exploited Vulnerabilities Guide is a useful reference point.

Risk and Threat Considerations

Active exploitation changes this from a patch-management issue into an intrusion-response issue. Because the flaw sits in Apple kernel code, an attacker who reaches exploitation may gain a much stronger foothold than a typical app-level compromise, including the ability to hide activity or chain into broader access.

Failure mechanism: The vulnerability allows an application to execute code with kernel privileges, so a malicious actor only needs a workable path to trigger the flaw on a reachable device, then use the elevated execution to persist, collect data, or stage additional abuse.

Impact: The main impact is device compromise with elevated authority, which can expose data, sessions, credentials cached on the device, and any enterprise services the device can reach. In managed fleets, a single compromised endpoint can become a pivot point for further access.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while 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 requires rapid prioritization and verification of exposure.
Recommendation — Prioritize, verify, and remediate exploited Apple devices first.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Are Identified and Recorded	The question turns on identifying vulnerable Apple assets before remediation decisions.
Recommendation — Inventory affected Apple endpoints and record exposed assets immediately.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This is a live vulnerability remediation decision tied to active exploitation.
	IR-4 — Incident Handling	Confirmed exploitation requires containment, evidence preservation, and response.
Recommendation — Remediate the Apple kernel flaw and track validation evidence to closure. Treat exposed devices as incident candidates and preserve evidence before cleanup.
MITRE ATT&CK	T1068 — Exploitation for Privilege Escalation	Kernel RCE is a privilege-escalation exploitation path with post-compromise impact.
Recommendation — Hunt for privilege escalation signs and follow-on execution on exposed devices.

Practitioner Guidance

What to verify: Confirm whether any Apple device in scope was reachable during the active-exploitation period and whether logs show post-exploitation indicators such as unusual privilege changes, persistence, or unexpected management profile activity. Do not stop at “patched now” if the device may already have been touched.

Decision rule: If you cannot prove the device was not exposed before remediation, treat it as potentially compromised, preserve evidence, and investigate before returning it to normal trust. If the device handles sensitive enterprise access, rotate any credentials or sessions that could have been present on the endpoint during the exposure window.

Practitioner takeaway: For a KEV-listed Apple kernel RCE, the important judgment is whether the device was exposed before the fix, because confirmed exploitation evidence matters more than version speculation.

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