Is CVE-2021-37975 (Google Chromium V8 Use-After-Free) being exploited in the wild?

What “exploited in the wild” means for this CVE

For a browser engine CVE, “being exploited in the wild” means there is evidence that real attackers have used the flaw, or are actively using it, outside a lab or proof-of-concept setting. That changes the question from abstract vulnerability awareness to operational response, because the priority becomes exposure confirmation, containment, and hunting for compromise rather than simply tracking a known weakness.

That distinction matters because browser exploitation often starts with something ordinary-looking, such as a crafted page, then turns into memory corruption and code execution. For a high-volume target like Chromium, even a single confirmed exploitation pattern can justify faster response across managed endpoints and user populations.

How to confirm whether your environment is exposed

The first step is to determine whether your endpoints, browser channels, and embedded Chromium components are still running vulnerable builds. If you manage browsers centrally, confirm inventory through device management, software inventory, and version reporting rather than relying on user reports. Where Chromium is embedded in another product, treat that product as part of the exposure surface, because the vulnerable engine may not be obvious from the user interface.

For a vulnerability that reaches users through web content, exposure is not limited to direct browser installs. A hosted app, remote support tool, desktop wrapper, or third-party application using Chromium components can all inherit the same risk path. That is why vulnerability management needs asset scope and component mapping, not just package names. Vulnerability Management Guide is useful here because it frames KEV status, verification, and remediation prioritisation as an operational process rather than a one-off patch task.

Why this vulnerability is treated as urgent

Active exploitation changes the response threshold. Once a CVE appears in CISA’s Known Exploited Vulnerabilities catalogue, it is no longer just a theoretical browser bug to be scheduled into a normal patch cycle. The practical assumption should be that exploit code, exploit chaining, or opportunistic scanning may already exist in the wild, so delay increases the chance of initial compromise or re-compromise.

Memory corruption in a browser engine is especially concerning because the browser is both a high-trust user interface and a common delivery vehicle for remote content. A use-after-free in V8 can be used as a first stage for further exploitation, especially if an attacker can combine it with sandbox escape, credential theft, or post-exploitation browser abuse. Zero-Day and Exploited Vulnerabilities Guide is a strong companion for the response model because it focuses on KEV triage, emergency mitigation, and post-patch hunting. For a broader browser-hardening perspective, Enterprise Browser and Browser Security Guide helps frame the surrounding controls that limit damage if browser code execution is reached.

What to do if patching cannot happen immediately

If you cannot patch at once, reduce the ways the browser can be used as a delivery path. That means tightening browser policy, reducing exposure to untrusted web content, constraining extension risk, and using isolation or sandboxing where available. The goal is not to “solve” the CVE without a fix, but to shrink the number of endpoints and sessions that can be reached before remediation lands.

When remediation is delayed, focus on compensating controls that reduce exploit opportunity and post-exploit impact. Review whether high-risk users, admins, or developers have broader browser access than necessary, and consider whether remote browser isolation or hardened browser profiles are available for the most exposed groups. If the same platform also stores credentials or session material, then the browser becomes part of the attack path, not just the victim application. Enterprise Browser and Browser Security Guide is relevant because it covers browser hardening, isolation, and credential-theft exposure in the same operational context.

Risk and Threat Considerations

A browser engine use-after-free is a practical exploitation risk because the attacker only needs a user to render crafted content, and the browser itself is a trusted execution environment on most endpoints. Once a flaw like this is actively exploited, the main concern is not just crashing a process, but gaining a foothold for code execution, credential theft, or chained exploitation on a managed device.

Failure mechanism: A crafted page triggers memory corruption in the V8 engine, which can be used to destabilise execution and potentially step toward arbitrary code execution or other follow-on abuse.

Impact: Successful exploitation can expose the browser process, user session material, and any downstream access available from the endpoint, which is why KEV-listed browser flaws deserve rapid containment and verification.

Practitioner Guidance

What to verify: Confirm that every managed endpoint has picked up the vendor fix or a documented compensating control, and verify embedded Chromium components as well as standalone browsers. If you only check the primary browser binary, you can miss secondary products that still carry the vulnerable engine.

What to prioritise: Triage internet-facing users, privileged users, and high-value endpoints first, then assess whether any of those systems accessed suspicious pages or showed browser crash, hang, or anomaly patterns around the exposure window. In practice, active exploitation means patching and exposure reduction should outrank routine vulnerability backlogs.

Practitioner takeaway: For a KEV-listed browser engine flaw, the correct operational posture is to assume exposure is actionable until proven otherwise, then combine rapid patching with compromise hunting and browser hardening.

Related resources from NHI Mgmt Group

• Is CVE-2021-4102 (Google Chromium V8 Use-After-Free) being exploited in the wild?
• Is CVE-2021-37973 (Google Chromium Portals Use-After-Free) being exploited in the wild?
• How do you patch or mitigate CVE-2021-37975 (Google Chromium V8 Use-After-Free)?
• Is CVE-2021-30633 (Google Chromium Indexed DB API Use-After-Free) being exploited in the wild?