CVE-2021-30661 is a webkit storage use-after-free vulnerability in Apple Multiple Products. CISA added it to the Known Exploited Vulnerabilities catalogue on 3 November 2021, which means attackers have used it in real attacks. Apple iOS, iPadOS, macOS, tvOS, watchOS, and Safari WebKit Storage contain a use-after-free vulnerability that leads to code execution when processing maliciously crafted web content.
What this vulnerability means in WebKit-powered Apple products
A use-after-free in WebKit storage means the browser engine can keep using memory after it has been released. In Apple’s web-facing stack, that matters because malicious web content can trigger memory corruption during normal page processing, turning a browsing action into a code-execution path.
That class of flaw is dangerous because WebKit is shared across multiple Apple products, so a single weakness can have a broad blast radius. It also fits the pattern of memory-safety bugs that can be chained with other weaknesses for deeper compromise, which is why Apple platform and browser issues are often treated as high-priority exposure.
Why exploitability is so high for browser engine bugs
Browser engine vulnerabilities are attractive to attackers because the delivery mechanism is often just a crafted webpage or embedded web content. The victim does not need to install a separate payload first, only to process attacker-controlled input in a trusted application.
For a reader tracking real-world exposure, the key point is that this CVE was added to the CISA KEV catalogue on 3 November 2021, which signals confirmed exploitation in the wild. For version and patch specifics, use the vendor advisory and the CVE Program record together with the NIST National Vulnerability Database.
How organisations assess exposure and scope
Exposure checks start with an accurate inventory of Apple endpoints, browsers, embedded WebKit consumers, and any internet-facing systems where users regularly process untrusted web content. If the estate is large, the practical question is not only whether a device is patched, but whether it can still reach hostile content before remediation is complete.
Priority should go to systems that are both reachable from the internet and likely to browse untrusted pages, because those systems have the shortest path from exploit delivery to impact. A structured Vulnerability Management Guide helps frame the basic workflow: identify assets, determine exposure, verify remediation, and track exceptions until closure.
Remediation, detection, and identity impact after compromise
Remediation should follow the vendor’s guidance as the authoritative source for fixed versions and rollout timing. Where immediate patching is not possible, reduce exposure by limiting untrusted browsing, tightening browser isolation where available, and prioritising the most exposed user groups first.
Detection should focus on suspicious browser crashes, abnormal WebKit process behaviour, and any signs that exploitation was followed by post-compromise activity. If exploitation is suspected, review whether session tokens, saved credentials, or other browser-accessible secret material may have been exposed, because browser compromise can turn a memory corruption event into broader account takeover risk.
Risk and Threat Considerations
This CVE is especially important because it combines a memory-corruption primitive with real-world exploitation in a widely used browser engine. The practical risk is not just a crash, but unauthorised code execution from content that a user may consider routine or benign.
Failure mechanism: The attacker supplies crafted web content that triggers use-after-free behaviour in WebKit storage, allowing controlled memory corruption and possible execution of attacker-supplied code.
Impact: Successful exploitation can lead to device compromise, user-session abuse, credential exposure, and follow-on lateral movement if the browser session had access to other services.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Tracks exploited CVEs and drives remediation priority for browser engine flaws. |
| Recommendation — Prioritise KEV-listed browser CVEs for rapid remediation and exception tracking. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Requires timely remediation of software flaws that enable code execution. |
| SI-4 — System Monitoring | Supports detection of exploitation, crashes, and abnormal process behaviour. | |
| Recommendation — Patch vulnerable WebKit components promptly and verify closure. Monitor browser and endpoint telemetry for signs of exploitation and post-exploit activity. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Memory safety failures in browser engines reflect secure architecture and coding concerns. |
| Recommendation — Use secure coding and memory-safety controls to reduce use-after-free defects. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Code execution outcomes from browser exploitation often enable staged post-compromise actions. |
| Recommendation — Hunt for follow-on execution patterns after suspected browser exploitation. | ||
Practitioner Guidance
Why practitioners should care: Treat exploited browser-engine CVEs as exposure-management problems, not just patching tickets. The most important operational judgement is usually which devices are most reachable by malicious content and therefore most likely to be hit before full remediation lands.
What to watch for: Prioritise users with heavy web exposure, recently observed browser instability, and systems that access sensitive accounts or administrative portals through WebKit-based browsers.