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

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2021-37973 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 Portals 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 “exploited in the wild” means for this Chromium CVE

For a CVE like this, “exploited in the wild” is not a theoretical label, it means defenders should treat the issue as an active exposure problem, not a future patch-planning item. CISA’s KEV inclusion is the practical signal that exploitation has been observed and that exposure needs immediate attention rather than routine vulnerability tracking.

In Chromium, that matters because browser flaws can be reachable through ordinary user activity, but the real risk is usually determined by whether the victim environment allows the attacker to reach the vulnerable execution path. For browser issues involving memory corruption or sandbox escape, the question is often not whether the bug exists, but whether a hostile page, extension, or chained exploit can hit a vulnerable browser population at scale.

When you read a KEV-listed browser CVE, the operational assumption should be that adversaries may already be chaining it with other browser or endpoint weaknesses. That is why active exploitation status changes priority more than the vulnerability label itself, and why browsers belong in the same urgent response workflow as endpoint and identity exposure when compromise is plausible.

How to confirm exposure and respond fast

Start by confirming whether the affected browser family is present anywhere in your estate, including managed desktops, developer systems, VDI pools, and any device that users rely on for web access. The practical test is simple: if the browser is deployed and not already remediated, treat the asset as potentially exposed until proven otherwise.

If patching is available, apply it through your normal browser update channel, but do not wait for a full maintenance window when a CVE is already in KEV. For high-value environments, browser remediation should be handled like an urgent security update with verification, not a best-effort software refresh. The authoritative version and fix details belong in the vendor advisory and the CISA KEV catalogue, not in an internal interpretation layer.

If patching must wait, reduce exposure immediately by restricting browsing to managed systems, limiting risky web content paths, and tightening browser policy where operationally feasible. For enterprise browser controls, the practical goal is to shrink the set of pages, extensions, and user actions that can reach the vulnerable code path. NHIMG’s Enterprise Browser and Browser Security Guide is a useful navigation point for hardening controls that reduce browser attack surface.

What to check after remediation

Because the direct answer says active exploitation is already known, remediation should be paired with a compromise check, not just a version check. Look for unusual browser crashes, suspicious renderer behavior, unexpected downloads, malicious extensions, and post-browse endpoint activity that does not fit normal user patterns. In browser exploitation cases, the first observable sign may be a second-stage payload, not the exploit itself.

Where endpoint logging exists, review whether the user session, browser profile, or adjacent process behavior changed around the suspected window of exposure. If the browser was used on a privileged workstation, or on a system that holds tokens, saved credentials, or developer secrets, treat the investigation as higher priority because browser compromise can become a foothold into broader account or service access. When browser compromise is suspected, rotate exposed credentials and revoke sessions before assuming the browser issue was contained.

Risk and Threat Considerations

A KEV-listed browser CVE changes the risk posture because it converts a code defect into a likely attack path. In practice, attackers target browser flaws for drive-by compromise, sandbox escape, or follow-on credential theft, and a use-after-free bug can be especially valuable when it is part of a chained exploit.

Failure mechanism: The vulnerable browser code path can be triggered by crafted web content, and the attacker may use that foothold to escape the renderer sandbox or stage a second exploit. Once the browser is compromised, the attacker can harvest session data, steal secrets, or pivot to other trusted applications.

Impact: The immediate effect is loss of browser trust boundaries, followed by possible endpoint compromise, credential exposure, and downstream account abuse. In enterprise settings, that can expand from a single workstation incident into a broader identity and access problem if sessions or stored secrets are reachable.

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, 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	Active exploitation requires urgent vuln tracking and verified remediation.
Recommendation — Prioritise and verify remediation for KEV-listed browser vulnerabilities.
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	KEV status changes priority and escalation for exploited vulnerabilities.
Recommendation — Escalate KEV-listed exploits through your risk triage process.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	A browser CVE in active exploitation needs rapid flaw remediation and verification.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-exploitation review depends on logs and telemetry from the exposure window.
Recommendation — Apply and verify remediation for the affected browser software. Review logs for signs of browser compromise during the exposure window.
OWASP ASVS	V16 — Security Logging and Error Handling	Compromise validation depends on useful browser and endpoint telemetry.
Recommendation — Preserve and inspect security logs that may show exploitation or follow-on activity.

Practitioner Guidance

What to prioritise: Prioritise remediation on endpoints that browse the internet with high privilege, store valuable sessions or credentials, or sit in developer and administrative workflows. Those systems turn a browser exploit into a materially larger incident.

Decision rule: If the vulnerable browser is present and patching is not yet complete, treat the system as exposed and shorten the window by combining update acceleration with temporary hardening, then verify the update actually landed.

What to verify: Confirm both the browser version and the surrounding exposure conditions, including extension state, profile persistence, and whether the affected device handled sensitive authentication material during the exposure window.

Practitioner takeaway: Once a browser CVE is in KEV, the right question is not whether exploitation is possible, but how quickly you can reduce attack surface, validate patching, and rule out follow-on compromise.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org