Is CVE-2020-6572 (Google Chrome Media 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-2020-6572 to its Known Exploited Vulnerabilities catalogue on 10 January 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Google Chrome Media contains a use-after-free vulnerability that allows a remote attacker to execute code via a crafted HTML page.

Why a Chrome media use-after-free belongs in the “exploited in the wild” category

CISA’s KEV listing is the practical signal that matters here: once a vulnerability is added, defenders should treat it as known active exploitation rather than a theoretical browser bug. For a browser flaw, that usually means drive-by exposure risk, malicious page content, and a short window before opportunistic attackers start packaging it into wider phishing or exploit-kit chains. See the CISA Known Exploited Vulnerabilities Catalog and the CVE Program record to anchor the vulnerability identification and exploitation status.

The underlying issue is a memory-safety weakness in browser media handling, which is especially sensitive because browsers process untrusted content continuously and at scale. A use-after-free in that path can turn ordinary web content into code execution if an attacker can shape the page, trigger the vulnerable logic, and survive the browser’s mitigation stack. That makes the exposure broad, user-driven, and difficult to spot after the fact.

For teams tracking exploited browser vulnerabilities, the important distinction is not whether the flaw sounds niche, but whether normal browsing can reach the vulnerable code path. If the answer is yes, then user exposure is determined by web traffic patterns, tab usage, embedded media, and how quickly endpoint management can force browser updates. That is why exploited browser CVEs often require the same urgency as more “obvious” remote code execution issues.

What to verify when a browser CVE appears in KEV

Start by confirming whether the affected browser is present on managed endpoints, virtual desktops, kiosks, and any bring-your-own-device population that is allowed to browse internal resources. Then check whether update enforcement is actually working, because a browser can be nominally “patched” in inventory while still vulnerable on machines that have not restarted or where auto-update is blocked.

For browser exploitation, verification should also include whether the environment permits risky content paths such as unrestricted web access, unmanaged extensions, or user-installed plugins. The Enterprise Browser and Browser Security Guide is useful here because browser hardening is not just about the browser binary, it is also about policies, isolation, extension control, and reducing the attack surface around saved credentials and browser-based attacks.

If patching lags, treat the absence of a confirmed exploit in your own logs as weak evidence. Browser exploitation frequently leaves only indirect indicators, so the better question is whether the vulnerable browser version was reachable during the relevant window and whether suspicious downloads, anomalous child processes, or unusual page rendering events followed.

How to respond when patching must wait

If immediate remediation is not possible, reduce the chance that the vulnerable code path can be reached and reduce the blast radius if it is. In practice that means restricting unnecessary browsing, tightening extension allowlists, using isolation for higher-risk web activity, and prioritising the browser on devices that reach sensitive systems or hold privileged session cookies.

Browser vulnerability response is also a triage exercise. The Zero-Day and Exploited Vulnerabilities Guide and the Vulnerability Management Guide both reinforce the same operational rule: when a flaw is in KEV, prioritise exposure reduction, emergency mitigation, and validation of remediation rather than waiting for normal patch cycles.

Where the browser is used to access high-value web apps, also consider whether saved sessions, password stores, or federated login cookies may have been exposed before remediation. A browser exploit can be a foothold rather than the end goal, so containment may need to include session revocation and credential rotation if there is any sign that the attack moved beyond the browser process.

Risk and Threat Considerations

Browser exploitation is attractive because the user does the delivery work for the attacker. A crafted page or malicious ad can reach the vulnerable media parser without requiring a separate foothold, which makes the attack path scalable and noisy only after compromise has already started.

Failure mechanism: A use-after-free can let attacker-controlled content influence memory the browser no longer owns, creating the conditions for code execution, crash, or follow-on exploitation depending on the browser’s mitigations and the page’s trigger path.

Impact: Successful exploitation can lead to arbitrary code execution in the browser context, followed by credential theft, session hijacking, malware download, or pivoting into internal applications that trust the user’s browser session.

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	Browser KEV exposure is a vulnerability prioritisation problem.
Recommendation — Prioritise and verify remediation for KEV-listed browser vulnerabilities across all managed endpoints.
NIST CSF 2.0	PR.PS-01 — Configuration Management	Browser hardening and enforced update settings are configuration controls.
	DE.CM-09 — Configuration Monitoring	Browser drift and failed update enforcement need continuous monitoring.
Recommendation — Enforce secure browser configuration and update settings on managed devices. Monitor endpoints for browser version drift and failed remediation states.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	KEV-listed browser flaws require prompt flaw remediation and validation.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation depends on finding vulnerable browser instances.
Recommendation — Remediate the browser flaw quickly and verify the fix is effective. Scan endpoints to identify vulnerable browser installations and lagging updates.

Practitioner Guidance

What to prioritise: Treat KEV-listed browser flaws as endpoint exposure problems first, not just patch tickets. The first decision is whether you can remove reachability quickly through forced update, restart enforcement, or temporary browsing restrictions on high-risk user populations.

What to verify: Confirm both software version and effective exposure. A browser that is “installed” but not restarted, or one that is protected by policy exceptions, is still a live risk. Validate the controls that actually constrain browser execution, extension use, and session persistence.

Practitioner takeaway: For browser CVEs, active exploitation usually matters more than the technical novelty of the bug, so the right response is to reduce reachability, confirm remediation on real endpoints, and assume the browser may already have carried the attacker farther than the initial exploit path.

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