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

Yes. CISA added CVE-2021-1870 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, 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 macOS WebKit contain an unspecified logic vulnerability that allows a remote attacker to execute code. Any organisation running the affected product should treat remediation as urgent.

What this exploitation status means for Apple WebKit exposure

This is not a “watch and wait” vulnerability. Once a WebKit flaw is in CISA’s KEV catalogue, the operational question changes from possibility to exposure management: determine where the affected Apple platforms exist, whether browsers and in-app web views are still reachable, and whether the organisation has any unmanaged or out-of-policy devices that can still receive web content.

For teams that track web-facing attack surface, the key issue is not only the operating system version, but also the reachability of WebKit through normal user activity, embedded browsers, and mobile device fleets. A widely used browser engine can turn ordinary browsing into an exploit path, so inventory and enforcement matter as much as patch approval.

A practical response is to align triage with CISA Known Exploited Vulnerabilities Catalog status, then verify which Apple-managed devices are within the remediation window and which are exempted, delayed, or blocked by mobile device management rules.

How to respond when patching or updating is delayed

If remediation cannot happen immediately, the goal is to reduce the chance that a successful exploit becomes a full device compromise. That means tightening exposure around browsing, limiting high-risk web content on the most sensitive users and devices, and making sure remote support, endpoint telemetry, and asset visibility are strong enough to spot abnormal process launches or post-exploitation behaviour.

On Apple endpoints, delayed remediation should never become open-ended. WebKit exploitation is attractive because it can be triggered through ordinary content, so compensating controls are only a temporary bridge. Keep the exception narrow, time-bound, and owned by a named team with a clear update plan.

The vendor’s advisory should remain the source of truth for product scope and fix details, while NIST National Vulnerability Database and the CVE Program provide the record you should use to cross-check the identifier, naming, and downstream vulnerability references.

What to check for signs of earlier compromise

Because the issue is remotely exploitable, the right follow-up is not limited to installing the fix. Look for signs that the device was already used as an initial access point, especially if it handled sensitive mail, browser sessions, enterprise portals, or corporate web applications during the exposure window.

Useful checks include unusual browser crashes, unexpected child processes from web content, suspicious downloads, new configuration profiles, altered security settings, unexplained session reauthentication, and endpoints that show evidence of post-exploit tooling or data access. If the device was used for privileged workflows, also review whether browser sessions, saved credentials, or active tokens could have been exposed during the compromise window.

Where validation is needed, compare device telemetry with the timing in the KEV catalogue entry and the corresponding vendor advisory, then decide whether incident response should treat the endpoint as potentially compromised rather than merely out of date.

Risk and Threat Considerations

WebKit exploitation on Apple platforms matters because it can convert a routine web interaction into code execution on a widely deployed endpoint. That creates risk not only to the device itself, but also to any browser-resident credentials, corporate sessions, or downstream services accessible from that device.

Failure mechanism: A remote attacker delivers crafted web content that triggers the WebKit logic flaw, gains code execution in the browser context, and then attempts to move from initial execution to broader device or account compromise.

Impact: The result can include data theft, session hijacking, further malware deployment, and a larger incident if the endpoint is trusted for access to email, SaaS, or administrative applications.

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	DE.CM-01 — Networks and network services are monitored to find potentially adverse events	Active exploitation requires monitoring for suspicious browser and endpoint behaviour.
	RS.MA-01 — Response plan is executed during or after an event	KEV-listed exploitation requires a defined response path when compromise is suspected.
Recommendation — Monitor Apple endpoints for exploit indicators and anomalous web-process activity. Trigger your incident response plan when exploitation or compromise is suspected.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The question is about urgent remediation of an actively exploited vulnerability.
	IR-4 — Incident Handling	When exploitation is in the wild, compromise assessment and response actions become necessary.
Recommendation — Prioritise and document remediation for the WebKit flaw across affected Apple devices. Investigate affected devices for evidence of exploitation and contain suspected incidents.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV status directly informs urgent vulnerability prioritisation and remediation.
Recommendation — Use KEV status to prioritise patching and validate remediation completion.

Practitioner Guidance

What to prioritise: Treat any KEV-listed browser-engine issue on actively used endpoints as a high-priority remediation item, especially where the devices are used for business email, admin portals, or sensitive browsing. If patching is delayed, focus first on reducing exposure from the most privileged or highest-value users.

What to verify: Confirm the affected fleet, confirm update success at the device level, and confirm whether browser sessions or credentials on those devices should be rotated if there is evidence of compromise or credible exposure.

Practitioner takeaway: For remotely exploitable browser-engine flaws, the meaningful decision is not whether exploitation is possible, but whether your organisation can prove the vulnerable devices are either patched or no longer trusted.