Is CVE-2021-30633 (Google Chromium Indexed DB API Use-After-Free) being exploited in the wild?

Yes. CISA added CVE-2021-30633 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. Google Chromium Indexed DB API contains a use-after-free vulnerability that allows a remote attacker, who has compromised the renderer process, to potentially perform a sandbox escape via a crafted HTML page.

What “being exploited in the wild” means for this CVE

This is not a theoretical browser weakness. Once CISA places a vulnerability in the CISA Known Exploited Vulnerabilities Catalog, the practical assumption should be that real attackers have a working path to trigger it and that exposure can be operationally relevant even if exploitation is hard to observe locally. For CVE-2021-30633, the important question is whether vulnerable Chromium-based browsers are still present on endpoints that can reach untrusted web content.

The weakness sits in a browser execution path, so the first-principles risk is exposure through everyday browsing, not just through direct targeting of a high-value user. If an attacker can deliver a crafted page to a vulnerable browser version, the consequence is not limited to a crash, it can become a process boundary break that changes the incident from “browser bug” to “potential endpoint compromise.”

For authoritative record details, use the CVE Program and the vendor advisory rather than secondary summaries when you are confirming the exact record, publication trail, and remediation guidance.

Why this vulnerability is security-relevant in practice

A use-after-free in browser code matters because browsers are already a high-trust execution environment with rich parsing, scripting, and sandboxing complexity. When the weakness is in Indexed DB handling, the practical concern is memory corruption in a component that is reachable from web content, which makes the exploit path suitable for drive-by delivery and for chaining with a second-stage escape or post-exploitation action.

That is why CISA KEV status is operationally significant: it tells defenders to treat exposure as urgent and to prioritise confirmation of vulnerable browser estates over speculative risk scoring alone. If you need a broader vulnerability-prioritisation workflow around active exploitation, the FIRST EPSS service can complement KEV by helping rank patching work, but KEV should drive the immediate response when a record is already confirmed exploited.

For teams that manage large desktop populations, browser exploitation is often a supply-side problem as much as a patch problem. The real issue is how quickly managed browsers update, whether users can delay restarts, and whether older installations remain in circulation on unmanaged or semi-managed endpoints.

What to do when patching is not immediate

If you cannot remediate at once, narrow the attack surface first: reduce exposure to untrusted browsing, tighten browser update enforcement, and verify that the vulnerable renderer path is not broadly reachable on endpoints that process sensitive work. That is especially important for shared workstations, privileged users, and systems where browser compromise could pivot into credentials, session tokens, or internal web applications.

Where browser hardening is part of your program, align the response with a broader browser-security baseline such as the Enterprise Browser and Browser Security Guide. The key operational move is to combine version control, extension control, and policy enforcement so vulnerable browsers do not remain a durable attack path.

If you need a threat-model view of how browser exploitation turns into broader compromise, use the Zero-Day and Exploited Vulnerabilities Guide as a response framework for triage, containment, and post-patch validation. Even though this CVE is not a zero-day in the strict sense today, the response pattern is the same: assume active probing, confirm exposure fast, and validate that the fix actually removed the reachable condition.

Risk and Threat Considerations

The main risk is not just code execution in isolation, it is the combination of web-delivered exploitability and a browser sandbox escape path. That means an attacker can use ordinary web traffic to reach the vulnerable code path, then try to expand from browser execution to broader endpoint access or credential theft.

Failure mechanism: A crafted page triggers the use-after-free in the Chromium Indexed DB API, allowing memory corruption in a renderer-adjacent path and creating an opportunity for sandbox escape or chained compromise.

Impact: Successful exploitation can move the incident from a browser-facing vulnerability to endpoint exposure, including session theft, follow-on malware delivery, or access to internal applications opened from the same device.

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

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited browser CVEs require rapid exposure discovery and remediation prioritisation.
Recommendation — Prioritise asset discovery, confirm vulnerable Chromium versions, and accelerate remediation for exposed endpoints.
NIST CSF 2.0	PR.IP-12 — Vulnerability Management	KEV-listed exploitation directly maps to vulnerability handling and remediation governance.
Recommendation — Track the CVE in your vulnerability workflow and drive remediation to verified closure.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This CVE requires timely flaw remediation and validation across affected browser estates.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure must be confirmed by monitoring and scanning for vulnerable browser instances.
Recommendation — Apply and verify browser remediation promptly across managed endpoints. Scan for affected browser builds and maintain continuous exposure monitoring.

Practitioner Guidance

What to verify: Confirm whether managed endpoints are still running vulnerable Chromium builds, including secondary browsers and embedded Chromium-based applications. Do not assume the main browser fleet is the only exposure path.

Decision rule: If the browser can reach untrusted content and the device is used for privileged or sensitive work, treat this as a high-priority remediation item even if you have not observed exploitation locally.

What practitioners underestimate: Browser exploitation often survives as a persistence or re-entry path when patching is uneven, so the highest-value work is exposure confirmation, enforced update timing, and post-remediation validation, not just checking that a patch ticket exists.

Practitioner takeaway: For KEV-listed browser CVEs, the defensible posture is to assume exposure matters until proven otherwise, then verify patch state, update enforcement, and any evidence of suspicious browser activity before you close the ticket.