Is CVE-2025-6558 (Google Chromium ANGLE and GPU Improper Input Validation) being exploited in the wild?

Yes. CISA added CVE-2025-6558 to its Known Exploited Vulnerabilities catalogue on 22 July 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Google Chromium contains an improper input validation vulnerability in ANGLE and GPU. Any organisation running the affected product should treat remediation as urgent.

What CISA’s KEV listing means for this Chromium issue

The practical answer is not just that the flaw exists, but that it has crossed the threshold for known active exploitation. When CISA places a CVE in the KEV catalogue, it is signalling that defenders should treat exposure as real, current, and operationally urgent rather than theoretical. For this case, that means the browser and any embedded Chromium-based components should be prioritised for rapid inventory and remediation.

For vulnerability handling, the key question is whether the affected product is present anywhere in the environment, including managed desktops, virtual desktops, kiosks, and browser-integrated enterprise software. The CISA Known Exploited Vulnerabilities Catalog is the authoritative place to confirm that status and track the response expectation attached to it.

Why improper input validation in ANGLE and GPU is security-relevant

Improper input validation in browser graphics code is serious because rendering paths sit close to complex parsing, memory handling, and hardware-accelerated execution. A flaw in ANGLE or GPU processing can give attackers a route from ordinary web content into deeper browser execution paths, which is why browser exploitation chains often favour graphics and media subsystems. The issue is not whether users deliberately install anything malicious, but whether a hostile page or content path can trigger unsafe processing.

This is one of the reasons browser and graphics defects tend to be treated as high-risk even before a full public exploitation narrative is available. The primary control objective is to reduce the time window in which an exposed endpoint can be reached through a vulnerable browser build. The NIST Cybersecurity Framework 2.0 maps well to that objective because it pushes inventory, protection, detection, response, and recovery as a single operational cycle.

What to do while you confirm exposure and remediate

The first decision is whether the vulnerable Chromium version is actually deployed in your fleet or exposed through another product that bundles Chromium components. If it is, treat browser update rollout as urgent and do not wait for a routine patch window. If you cannot patch immediately, reduce exposure by limiting access to untrusted web content, tightening browser policy where practical, and watching for suspicious browser crashes, unusual renderer behaviour, or related endpoint alerts.

Confirm which endpoints, virtual desktops, and managed applications use the affected Chromium build.
Apply the vendor fix or approved update path as soon as it is available in your environment.
If patching must wait, narrow exposure to untrusted browsing and prioritise higher-risk user groups first.
Review logs and endpoint telemetry for signs that the browser may already have been used as an access path.

For teams that need a process reference, Zero-Day and Exploited Vulnerabilities Guide aligns closely with the response pattern here: validate exploitation, accelerate remediation, and hunt for compromise after the fact rather than assuming patching alone resets the risk.

Risk and Threat Considerations

Browsers are high-value attack surfaces because they sit at the boundary between trusted enterprise access and untrusted external content. Once a flaw is being exploited in the wild, attackers can use it for drive-by compromise, user-targeted exploitation, or as an initial foothold that leads to session theft, malware delivery, or further exploitation of the host.

Failure mechanism: Unsafe validation in ANGLE or GPU handling can let maliciously crafted input reach a code path that was not designed to trust it, creating a browser exploitation condition that bypasses normal user intent and security expectations.

Impact: Successful exploitation can result in endpoint compromise, credential or session exposure, and a reliable initial access path that defenders may not notice until after the browser session has already been abused.

Standards & Framework Alignment

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

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
NIST CSF 2.0	ID.AM-01 — Physical Devices and Systems Inventoried	Browser exposure depends on knowing where Chromium-based software is deployed.
	PR.PS-02 — Software Platform Integrity	A browser exploitation issue is reduced by controlled, timely software updates.
	DE.CM-07 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software	Active exploitation of a browser flaw warrants monitoring for suspicious endpoint behaviour.
Recommendation — Inventory Chromium-based software and exposed endpoints before prioritising remediation. Deploy the fixed browser build through managed software update controls as soon as possible. Watch endpoints for browser crashes, exploit indicators, and post-exploitation activity.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This CVE requires rapid correction through patching or approved mitigation.
Recommendation — Patch or mitigate the vulnerable Chromium build without waiting for routine maintenance windows.

Practitioner Guidance

What to verify: Do not stop at “Chrome is installed.” Verify the exact Chromium-based products in use, because browsers, embedded web views, and packaged enterprise software may have different update cadences and different exposure profiles.

Decision rule: If the vulnerable build is present on a system that can reach the internet or receive untrusted web content, prioritise update deployment ahead of lower-severity maintenance work. If a patch is delayed, treat that delay as a temporary risk acceptance decision, not a normal scheduling choice.

Practitioner takeaway: For a KEV-listed browser flaw, remediation urgency should be driven by exposure plus confirmed active exploitation, not by whether you have already seen abuse in your own environment.