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

Yes. CISA added CVE-2022-22675 to its Known Exploited Vulnerabilities catalogue on 4 April 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. macOS Monterey contains an out-of-bounds write vulnerability that could allow an application to execute arbitrary code with kernel privileges. Any organisation running the affected product should treat remediation as urgent.

What “actively exploited” means for CVE-2022-22675

CISA’s KEV listing is the key signal here: if a vulnerability is in that catalogue, practitioners should assume real-world exploitation, not just theoretical risk. For this macOS issue, the practical question is not whether exploitation is possible, but whether affected Apple systems are still exposed and whether remediation has already been completed.

Because the flaw is an out-of-bounds write in macOS Monterey, the security concern is kernel-level impact. That changes the response threshold: even if the vulnerable code path seems narrow, a kernel-privilege outcome means successful exploitation can materially affect system integrity, containment, and trust in the host.

How to confirm whether you are exposed

Start with asset scope, then check the installed macOS build and model coverage against Apple’s advisory and CISA’s KEV entry. If you cannot confidently prove that affected hosts are absent, treat the environment as exposed until proven otherwise. For exploited vulnerabilities, uncertainty is a risk condition, not a safe holding pattern.

Use the CISA Known Exploited Vulnerabilities Catalog for the exploitation status signal, and cross-check the product record in the NIST National Vulnerability Database and the Apple security advisory for environment-specific applicability.

If your fleet includes multiple macOS versions, do not assume the finding is isolated to one ring or one department. Endpoint inventory gaps, unmanaged laptops, and long-lived test systems are common reasons exploited vulnerabilities persist after an advisory is published.

Why urgent remediation is the right response

KEV inclusion means the defender should prioritise this ahead of ordinary patch queues. The right response is to apply Apple’s fix as soon as operationally possible, then verify that every instance in scope actually received it. The vulnerability class matters less than the KEV status and kernel impact, because both increase the consequence of delay.

Reference the vendor advisory for the exact fixed release, then use your patch-management process to confirm installation rather than relying on change approval alone. Where you use FIRST EPSS in prioritisation, treat it as supporting triage, not a substitute for KEV-driven urgency.

If the host is business critical and must remain online while you remediate, reduce exposure by restricting who can log on, limiting untrusted software execution, and tightening monitoring around privilege escalation or unexpected kernel activity. Those compensating steps are temporary controls, not a reason to defer patching.

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

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	CVE exposure depends on identifying affected macOS assets.
Recommendation — Inventory macOS assets and tag vulnerable hosts for urgent remediation.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	The question is about exploited vulnerability triage and urgent patching.
Recommendation — Prioritise KEV-listed macOS vulnerabilities for immediate remediation.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Defenders need continuous discovery and validation of vulnerable systems.
	SI-2 — Flaw Remediation	KEV-listed flaws require prompt fix deployment and verification.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-compromise review is important after active exploitation is known.
Recommendation — Scan and verify affected endpoints until remediation is confirmed. Apply the vendor fix quickly and confirm installation on every affected host. Review logs for suspicious privilege changes and persistence after exposure.

Practitioner Guidance

What to verify: Confirm both exposure and closure. A system is not safe until you can show the vulnerable Apple build is gone, the fix is installed, and the host has not been rebuilt from a stale image that still contains the same version.

Decision rule: If a macOS endpoint is internet-facing, broadly used, or handles sensitive internal data, treat a KEV-listed kernel flaw as a high-priority remediation item even before you have evidence of abuse. If patching must wait, escalate it as an exception with an expiry date and compensating monitoring.

What practitioners underestimate: Post-exploitation validation matters. When a kernel-impacting flaw is known to be exploited, review for anomalous privilege changes, new persistence mechanisms, suspicious launch items, and signs that the host may have been used as a foothold before remediation.

Practitioner takeaway: For KEV-listed macOS flaws, the operational decision is usually not whether to patch, but how quickly you can prove fleet-wide remediation and whether any host needs compromise assessment before it is trusted again.