Is CVE-2020-9907 (Apple Multiple Products Memory Corruption) being exploited in the wild?

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

Yes. CISA added CVE-2020-9907 to its Known Exploited Vulnerabilities catalogue on 27 June 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Apple iOS, iPadOS, and tvOS contain a memory corruption vulnerability that could allow an application to execute code with kernel privileges.

What “being exploited in the wild” means for a CISA KEV-listed CVE

For this question, the practical answer is yes because CISA has already put the issue into the KEV catalogue, which is its operational signal that exploitation has been observed and defenders should treat the weakness as active, not theoretical. The key point is not just that the flaw exists, but that exposure now carries a time-sensitive response requirement.

When a vulnerability reaches KEV status, incident handling shifts from routine patch tracking to urgent exposure validation, remediation, and compromise assessment. That is why CISA Known Exploited Vulnerabilities Catalog is the authoritative reference for the exploitation signal and remediation expectations.

What the flaw changes in practice for Apple devices

The underlying issue affects Apple iOS, iPadOS, and tvOS and is described as a memory corruption condition that could let an application execute code with kernel privileges. In practical terms, that means the impact is not limited to app instability. A successful exploit can cross the normal trust boundary between an application and the operating system kernel, which is where compromise becomes materially more serious.

That is also why the problem should be treated as a platform security event rather than a single-app bug. Kernel-level execution can create broad device exposure, so defenders should use the vendor advisory and the KEV entry together to confirm the exact build impact and the current remediation path. For recordkeeping and version validation, the CVE Program and the NIST National Vulnerability Database are the standard references.

How to respond when a mobile OS vulnerability is already being exploited

For actively exploited mobile platform flaws, the first task is to identify exposed devices and verify whether they are actually on the affected product line and build train. The second is to apply the vendor fix or mitigation as soon as it is available, then confirm deployment rather than assuming the update succeeded. Where device fleets are managed, this should be handled as an urgent patch-and-verify cycle, not as a normal maintenance window.

If patching must wait, isolate the highest-risk devices and reduce the likelihood of attacker reuse by limiting unneeded app installation, restricting risky sideloading paths where policy allows, and watching for abnormal crash patterns, privilege-related alerts, or other signs that the device may already have been touched. For a structured response to exposed and actively exploited flaws, the Zero-Day and Exploited Vulnerabilities Guide and the Vulnerability Management Guide provide the operational sequencing practitioners use for KEV-driven triage.

Risk and Threat Considerations

Once a mobile operating-system flaw is confirmed as exploited, the main risk is not only code execution, but the possibility of deeper device compromise through kernel privilege. That can turn an ordinary app foothold into access that is harder to detect, harder to contain, and more likely to survive basic user-level cleanup.

Failure mechanism: Exploitation of the memory corruption bug can let an application escape normal privilege boundaries and run code with kernel-level authority, which increases the chance of full device compromise.

Impact: The device may be exposed to stealthier persistence, security control bypass, data access, and broader abuse of trusted mobile services, especially before the flaw is patched or the device is reimaged.

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 SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited CVEs require urgent identification, prioritisation and remediation across assets.
Recommendation — Prioritise and remediate KEV-listed vulnerabilities on exposed devices without delay.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This question hinges on validating exposure and tracking an actively exploited vulnerability.
	SI-2 — Flaw Remediation	The issue calls for rapid correction of a known exploited flaw and confirmation of update deployment.
Recommendation — Scan for affected Apple devices and verify remediation after patching. Apply the vendor fix quickly and confirm the vulnerable build is no longer present.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	KEV-driven response depends on identifying which assets are exposed to the vulnerability.
	RS.MA-1 — Incident Management Plan Execution	Active exploitation can require incident-style containment and response actions beyond routine patching.
Recommendation — Identify all Apple endpoints that could still carry the vulnerable software. Execute your incident response plan when exploitation indicators or delayed patching increase risk.

Practitioner Guidance

What to verify: Confirm whether any fleet or personally managed device is in scope for the affected Apple product family, then verify update status from the device management plane rather than relying on user self-report. For any unpatched device, treat exposure as current until you have positive evidence of remediation.

Decision rule: If a device can reach sensitive mail, enterprise apps, or managed credentials and is still unpatched, prioritise it over lower-value endpoints even when you have not yet seen exploitation indicators. If patching is delayed, move quickly to containment and a targeted compromise review instead of waiting for proof of abuse.

Practitioner takeaway: KEV listing means the vulnerability has crossed from advisory into active-risk territory, so the right question is no longer whether exploitation is possible, but whether you have already closed the exposure and checked for follow-on compromise.

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