CISA's required action for CVE-2021-37973 is to apply updates per vendor instructions. In practice, find every instance of Google Chromium Portals in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.
What patching means for a Chromium browser flaw like CVE-2021-37973
The practical answer is straightforward: treat this as a browser software update problem, not a workaround-first problem. You need to identify every Chromium-based deployment that could still be running the affected code path, then apply the vendor update package or approved mitigation everywhere it exists. If a system cannot be fixed promptly, remove it from internet-facing use or take it out of service until it can be brought back into a supported, patched state.
For browser flaws, the real exposure is often broader than a single desktop install. Managed browsers, embedded Chromium components, kiosk endpoints, VDI images, and packaged applications can all carry the same vulnerable engine, so inventory matters as much as the patch itself. If you only update the obvious user browser, you can leave behind the less visible copies that remain reachable or operational.
Once the update is in place, verify that the patched build is actually the one running in production. That means checking the browser version, confirming managed policy rollout where applicable, and validating that no alternate channel, cached installer, or unmanaged instance is still present on the network. For browser vulnerabilities with active exploitation, patch completion is only half the job, because you also need to look for signs that the weakness was used before remediation.
How to confirm exposure and reduce the blast radius
Start with software discovery, because “installed somewhere” is not the same as “secured everywhere.” Use asset inventories, endpoint management data, and any browser telemetry you already have to find Chromium builds, repackaged browser shells, and systems where the browser is effectively part of the application stack. Then compare that list against your patch state and exposure profile so you can prioritise the systems that are both vulnerable and reachable from the internet or from untrusted content.
If a fix is delayed, reducing exposure is the next best mitigation. That may mean disabling the affected browser path, restricting where the system can browse, removing direct internet access, or isolating the host so the vulnerable component is no longer exposed to hostile content. The goal is to remove the attack surface, not merely to postpone the patch indefinitely.
It also helps to distinguish managed and unmanaged endpoints. A centrally administered browser fleet is usually easier to verify than personal or exception-driven installs, and the latter often account for the gaps attackers exploit. If you cannot prove a browser instance is updated, treat it as untrusted until you can.
What to check after remediation
Because this flaw was used in the wild, post-patch review should focus on possible prior compromise, not just on whether the update succeeded. Review browser, endpoint, and proxy logs for suspicious downloads, unusual navigation chains, new child processes, or signs that the browser was used as the entry point for follow-on activity. Also check whether the compromised workstation had access to credentials, sessions, internal portals, or management consoles that could have been exposed after exploitation.
If the affected browser or host could have handled sensitive sessions, rotate anything that may have been reachable during the exposure window. That can include active sessions, cached authentication material, API keys, or other secrets stored or accessible through the browser context. The exact scope depends on what the endpoint could access, but the rule is simple: if the flaw could have enabled session theft or credential harvesting, do not assume patching alone closes the incident.
Operationally, this is a browser lifecycle problem, not a one-time patch task
Browser vulnerabilities age quickly because they sit on a high-frequency attack surface. That makes disciplined patch orchestration, exposure tracking, and verification more important than heroic manual response. You want a process that can find browser instances, enforce the approved build, prove rollout, and keep unmanaged copies from reappearing after remediation.
For browser security more broadly, NHIMG’s Enterprise Browser and Browser Security Guide is useful when you need to think beyond a single CVE and standardise browser hardening, policy control, and exposure reduction across the fleet.
For vulnerability handling itself, use your vulnerability management process to track this from discovery through verification, exception handling, and closure. The important judgment is not just whether the update exists, but whether every reachable copy of the vulnerable software has been accounted for and brought under control.
Risk and Threat Considerations
Browser use-after-free flaws are attractive because they can be triggered through ordinary user activity, which makes them efficient for attackers who want code execution or an initial foothold. When the flaw is known to be exploited in the wild, the risk is not theoretical, even if no compromise has yet been confirmed on your side.
Failure mechanism: A vulnerable Chromium instance processes crafted content or interaction in a way that lets an attacker corrupt memory, crash the browser, or potentially execute code on the endpoint. That can convert a routine browsing event into an entry point for session theft, payload delivery, or follow-on compromise.
Impact: The main consequence is endpoint compromise with downstream exposure of browser sessions, locally accessible credentials, internal applications, and any trusted network access available from that device. The longer a vulnerable browser remains exposed, the more chance an attacker has to hit it before patching is complete.
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 | Browser CVEs require asset discovery, prioritised remediation, and verification. |
| Recommendation — Track Chromium exposure, patch quickly, and verify closure across all endpoints. | ||
| NIST CSF 2.0 | PR.IP-12 — Vulnerability Management | This is a vulnerability remediation and verification problem with active exploitation risk. |
| Recommendation — Prioritise exposed Chromium instances and confirm remediation is complete. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | A vendor security update or mitigation is the required response to a software flaw. |
| SI-4 — System Monitoring | Post-patch log review is needed to look for signs of prior exploitation. | |
| Recommendation — Apply the vendor fix or approved mitigation and validate deployment. Review logs and alerts for indicators of exploitation after remediation. | ||
| OWASP ASVS | V13 — Configuration | Browser hardening and exposure reduction rely on secure configuration and controlled deployment. |
| Recommendation — Enforce managed browser configuration and remove unsafe exposure paths. | ||
Practitioner Guidance
What to prioritise: Patch the externally exposed and highest-trust endpoints first, then work through managed internal fleets and any less visible Chromium-based applications or shells. If a system cannot be updated quickly, remove its internet reach before accepting the delay.
What to verify: Confirm the running browser build, not just the installed package name, and verify that unmanaged or alternate browser copies are not still present. After remediation, validate that logs do not show suspicious activity during the exposure window.
Practitioner takeaway: With a browser CVE that has been exploited in the wild, the right response is patch, verify, and hunt, because successful remediation depends as much on finding every vulnerable instance and checking for earlier abuse as it does on applying the update.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2021-30633 (Google Chromium Indexed DB API Use-After-Free)?
- How do you patch or mitigate CVE-2021-37975 (Google Chromium V8 Use-After-Free)?
- How do you patch or mitigate CVE-2021-30554 (Google Chromium WebGL Use-After-Free)?
- How do you patch or mitigate CVE-2021-21206 (Google Chromium Blink Use-After-Free)?
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.
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