Is CVE-2021-30762 (Apple iOS WebKit Use-After-Free) being exploited in the wild?

What “exploited in the wild” means for this CVE

For this vulnerability, the practical question is not whether the bug exists in theory, but whether defenders should assume real attacker activity already exists. Once CISA places a CVE in the KEV catalogue, it is treating the issue as actively exploited, which changes triage priority, patch urgency, and how much confidence you can place in “we have not seen alerts yet.”

That matters because WebKit is part of the browsing surface, so exposure is often broader than a single application team expects. If the affected product is present on managed devices, personal devices used for work, or kiosk-style endpoints, the vulnerable code path may be reachable through ordinary browsing activity rather than a special admin workflow.

For vulnerability records and authoritative status, use the CISA Known Exploited Vulnerabilities Catalog and the CVE Program entry family as the source of truth, rather than relying on informal “exploit in the wild” claims.

Why WebKit use-after-free bugs are high-priority operationally

A use-after-free in a browser engine is dangerous because the attacker is targeting code execution in a component that routinely processes untrusted content. In practice, that means the attack surface is large, the trigger can be low-friction, and successful exploitation can happen before a user notices anything unusual.

This kind of weakness is especially serious on mobile platforms because the browser engine is shared across many apps and links that render web content. A user does not need to install a suspicious app for risk to exist, which is why browser-engine CVEs are often treated as urgent even when the affected system looks “ordinary” from an inventory standpoint.

For teams that need a broader pattern view, the Zero-Day and Exploited Vulnerabilities Guide is a useful reference for handling fast-moving exploitation, and the NIST National Vulnerability Database helps with record normalization and downstream vuln-management workflows.

What to check before you assume you are safe

First confirm where the affected product is actually present. For a browser-engine issue, that means checking the mobile estate, managed app fleet, and any devices that receive delayed operating-system updates. Exposure is often broader than the team that owns the endpoint management tool sees at first glance.

Then verify whether patching really happened, not just whether it was approved. For actively exploited issues, the common failure is a stale compliance view, a deferred reboot, or a device that missed the update window and remained reachable long after the vulnerability was publicly known.

The most useful operational companion here is the Vulnerability Management Guide, which frames the right sequence: scope, prioritize, remediate, verify, and measure. If you need to compare urgency signals, FIRST EPSS can complement KEV status, although KEV status should dominate when CISA has already confirmed exploitation.

Risk and Threat Considerations

Browser-engine exploitation is dangerous because it can turn a normal browsing session into code execution on a trusted endpoint. That creates a fast path from initial access to data theft, session abuse, or follow-on malware delivery, especially if the device holds corporate credentials or cached tokens.

Failure mechanism: A use-after-free can let crafted web content corrupt memory in a way that yields attacker-controlled execution inside the browser process or a related sandbox boundary.

Impact: Successful exploitation can expose the device, the user session, and any data or credentials accessible from that endpoint, which is why delayed patching materially increases blast radius.

Practitioner Guidance

What to prioritise: Treat KEV-listed browser-engine flaws as exposure-management issues, not just patch tickets. If the vulnerable platform is in your estate, move it ahead of routine backlog work and verify update completion at the device level, not only in the MDM or ticketing system.

What to verify: Confirm whether any impacted devices have logged suspicious browser crashes, unexpected app launches, or post-exploitation indicators around the exposure window. If patching lagged, assume the window for compromise may be larger than the deployment date suggests.

Practitioner takeaway: When a browser CVE is already in KEV, the right assumption is that exploitation risk is real until you have verified both remediation and absence of earlier compromise.

Related resources from NHI Mgmt Group

• Guide: Enterprise Browser and Browser Security Guide
• Is CVE-2022-22620 (Apple iOS, iPadOS, and macOS Webkit Use-After-Free) being exploited in the wild?
• How do you patch or mitigate CVE-2021-30762 (Apple iOS WebKit Use-After-Free)?
• Is CVE-2021-30661 (Apple Multiple Products WebKit Storage Use-After-Free) being exploited in the wild?
• Is CVE-2021-30858 (Apple iOS, iPadOS, macOS Use-After-Free) being exploited in the wild?