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

Yes. CISA added CVE-2022-42827 to its Known Exploited Vulnerabilities catalogue on 25 October 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Apple iOS and iPadOS kernel contain an out-of-bounds write vulnerability which can allow an application to perform code execution with kernel privileges.

What “exploited in the wild” means for this CVE

For a CVE like CVE-2022-42827, “exploited in the wild” means the issue is not just theoretical or reproducible in a lab. It has enough credible exploitation evidence to appear in CISA’s Known Exploited Vulnerabilities catalogue, which is the clearest public signal that defenders should treat it as actively abused rather than merely disclosed.

For mobile fleets, that changes the response from normal patch planning to exposure confirmation and urgent remediation. If the vulnerable Apple iOS or iPadOS build is still present anywhere, the relevant question is not whether exploitation is possible, but whether the device population has already been exposed long enough for compromise to have occurred.

Mobile Device Security Guide is the right internal starting point when you need to validate fleet scope, enrolment state, and the controls that govern iOS and iPadOS endpoints.

How to triage exposure and response priority

The first step is to confirm where Apple iOS and iPadOS are present, then determine which devices are managed, supervised, or otherwise outside your normal patch cadence. In practice, the fastest path is to segment by ownership, OS version lineage, and business criticality, then prioritise any device that can reach email, identity, cloud, or internal apps.

Because the flaw is an out-of-bounds write in the kernel, the practical concern is not a cosmetic app crash. A successful exploit can reach kernel privilege, which makes the issue much more serious than a typical user-space bug and increases the value of rapid fleet-wide detection, upgrade, and exception handling.

Zero-Day and Exploited Vulnerabilities Guide helps frame the emergency workflow for issues that are already being used operationally, while Vulnerability Management Guide supports the prioritisation logic for KEV-listed exposure.

CISA Known Exploited Vulnerabilities Catalog is the authoritative place to verify the KEV status and track CISA’s required action for this issue, while NIST National Vulnerability Database is useful for record cross-checking and vulnerability reference details.

What to do if you cannot patch immediately

If patching must wait, the goal is to reduce reachable exposure rather than pretend the risk is contained. That means tightening device access, reducing exposure to untrusted content and links, limiting privileged workflows on the affected devices, and removing any unnecessary access paths that would make a compromised handset more valuable to an attacker.

Because exploitation may already be happening in the wild, delay should be treated as a compensating-control problem, not as a reason to defer the decision. The most useful temporary controls are the ones that reduce the blast radius of a successful kernel compromise and make the device less useful as an initial foothold into enterprise services.

Zero-Day and Exploited Vulnerabilities Guide is also the best internal reference for emergency mitigation, hotpatching strategy, and compromise assessment after a temporary hold.

Risk and Threat Considerations

Kernel exploitation on a mobile device is high consequence because it can convert a client-side vulnerability into control over the operating environment itself. Even when the initial exploit starts from a single application or message path, the attacker may gain a foothold that is much harder to detect than ordinary app-level abuse.

Failure mechanism: An out-of-bounds write in the kernel can be used to corrupt memory in a way that yields code execution with kernel privileges, which shifts the issue from simple application instability to full device-level compromise.

Impact: A compromised mobile device can expose credentials, sessions, data, and enterprise access paths, and it may also become a staging point for follow-on intrusion if the device is trusted by email, MDM, or cloud applications.

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, OWASP ASVS and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited mobile CVEs require rapid discovery and remediation prioritisation.
Recommendation — Prioritise and remediate KEV-listed mobile vulnerabilities first.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This CVE response depends on confirming exposure and tracking remediation status.
	SI-2 — Flaw Remediation	Actively exploited vulnerabilities require prompt patching or mitigation.
Recommendation — Scan the fleet and track vulnerable iOS and iPadOS assets to closure. Apply the vendor fix or an approved mitigation without delay.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	KEV-listed exploitation is a direct technical vulnerability management case.
Recommendation — Track, assess and remediate the vulnerability through a formal process.
OWASP ASVS	V13 — Configuration	Mobile exploitation response depends on secure device and app configuration.
Recommendation — Verify device configuration and remove insecure exposure paths.
NIST CSF 2.0	RS.MA-01 — Response Plan Execution	The question is about active exploitation, which requires fast incident-style action.
Recommendation — Execute the response plan and accelerate containment for exposed devices.

Practitioner Guidance

What to prioritise: Treat any unmanaged or slow-to-update iOS and iPadOS device as higher risk than a fully supervised fleet device, especially if it can access email, VPN, SSO, or administrative portals. Those are the devices where compromise has the clearest path to secondary impact.

What to verify: Confirm the actual OS build across the fleet, not just the device model or enrollment status. For an actively exploited mobile CVE, the meaningful question is whether the vulnerable build is still reachable anywhere, including contractor-owned or exception devices.

Practitioner takeaway: For a KEV-listed mobile kernel flaw, the decision point is speed of exposure reduction, not certainty of exploitation on every endpoint. If the vulnerable build is still present, assume it deserves urgent treatment until the fleet is either remediated or convincingly constrained.