Join our Newsletter — 33% off our NHI Course
Home› Glossary› Threats, Abuse & Incident Response› CVE-2020-6572 (Google Chrome Media Use-After-Free)
Threats, Abuse & Incident Response

CVE-2020-6572 (Google Chrome Media Use-After-Free)

← Back to Glossary
By NHI Mgmt Group Updated October 17, 2026 Domain: Threats, Abuse & Incident Response

CVE-2020-6572 is an use-after-free vulnerability in Google Chrome Media. CISA added it to the Known Exploited Vulnerabilities catalogue on 10 January 2022, which means attackers have used it in real attacks. Google Chrome Media contains a use-after-free vulnerability that allows a remote attacker to execute code via a crafted HTML page.

What a use-after-free in browser media code means

A use-after-free happens when software keeps using memory after it has already been released. In browser media code, that is especially dangerous because the media pipeline processes complex, attacker-influenced content at high speed and with deep access to the browser’s rendering and decoding stack.

For CVE-2020-6572, the issue sits in Google Chrome Media and can be triggered through a crafted HTML page. The practical concern is not just a crash, but the possibility that malformed content can steer execution into stale memory and turn a parsing flaw into code execution.

Why this class of flaw is dangerous in Chrome

Media components are high-value targets because they handle rich, nested, and timing-sensitive data structures. When memory lifetime is mishandled, an attacker can sometimes shape allocator behavior, reuse freed objects, or corrupt program state in ways that bypass normal assumptions about safety.

Browser exploitation is particularly serious because the browser is a trusted gateway to credentials, sessions, corporate applications, and internal content. A successful exploit may not stop at a single tab, it can become a foothold for broader compromise inside the endpoint environment.

Use-after-free is a memory safety weakness, not a configuration problem. The danger comes from how reliably attackers can feed the vulnerable code path with crafted content and how difficult memory corruption bugs are to reason about once execution reaches freed objects.

How organisations assess exposure to CVE-2020-6572

Exposure assessment starts with inventory. Teams need to know where Google Chrome is installed, which versions are in use, which endpoints are internet-facing, and whether browser updates are centrally managed or left to local users.

The next question is whether users can reach untrusted HTML content through email, web browsing, chat links, embedded previews, or internal portals that render external content. The same vulnerability matters more when the browser is exposed to frequent untrusted input and less when access is tightly limited.

For authoritative version and patch details, use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog, and confirm the record through the CVE Program and NIST National Vulnerability Database.

Remediation, detection, and compromise review

Patch management is the primary remediation path, but browsers often require operational coordination because some organisations depend on pinned versions, managed rollout rings, or application compatibility testing. When immediate patching is not possible, limit exposure by reducing access to untrusted content and hardening browser execution paths.

Detection should look for suspicious browser crashes, unusual renderer behavior, exploitation chains that begin with web content, and post-exploitation activity on the host. After patching, review endpoints for signs that the vulnerability was already used before remediation, especially where the browser handled hostile pages or messages.

If compromise is suspected, treat browser sessions and related secrets as potentially exposed. Active web sessions, saved credentials, tokens, and connected service accounts may need review or rotation depending on what the attacker could reach after code execution.

Practical security meaning of KEV-listed browser bugs

A KEV-listed browser vulnerability should be treated as an active exposure, not a theoretical weakness. The operational question is whether your fleet can be patched quickly enough and whether compensating controls are strong enough to reduce the window of exploitation until update deployment is complete.

The broader lesson is that browser bugs often become enterprise risk because browsers are both user-facing and deeply privileged clients. Even when the original flaw is local to a media component, the real security impact comes from how much trust the browser already has in the user environment and in the content it renders.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
CIS Controls v8CIS-7 — Continuous Vulnerability ManagementCVE exposure and patch prioritization are core vulnerability management concerns.
Recommendation — Prioritise and remediate the Chrome vulnerability using continuous vulnerability management workflows.
NIST SP 800-53 Rev 5SI-2 — Flaw RemediationThis CVE is a software flaw requiring timely remediation and patch tracking.
SI-4 — System MonitoringExploitation and post-compromise review depend on monitoring for suspicious browser behavior.
SC-5 — Denial of Service ProtectionMemory corruption in browser media can destabilize availability and service integrity.
Recommendation — Track the browser flaw and verify remediation under SI-2. Monitor endpoints and browser telemetry for signs of exploitation under SI-4. Apply resilience controls that reduce the impact of browser crashes and instability under SC-5.
ISO/IEC 27001:2022A.8.8 — Management of technical vulnerabilitiesThis vulnerability is handled through technical vulnerability management and remediation.
Recommendation — Manage, prioritise, and verify remediation of the Chrome vulnerability under A.8.8.

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 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org