Is CVE-2022-4135 (Google Chromium GPU Heap Buffer Overflow) being exploited in the wild?

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

Yes. CISA added CVE-2022-4135 to its Known Exploited Vulnerabilities catalogue on 28 November 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Google Chromium GPU contains a heap buffer overflow vulnerability that allows a remote attacker, who has compromised the renderer process, to potentially perform a sandbox escape via a crafted HTML page.

How KEV listing answers the exploitation question

CISA’s Known Exploited Vulnerabilities catalogue is the practical signal here. When a CVE is listed there, CISA is saying there is reliable evidence of active exploitation, not just theoretical impact. That makes the question less about possibility and more about exposure management, verification, and whether affected Chromium deployments remain reachable in a browser-based attack path.

For operators, the key point is that exploitation of a browser gpu heap buffer overflow is usually not a mass compromise by itself. It becomes operationally serious when an attacker can first get code running in the renderer, then use the flaw to cross the sandbox boundary. That turns a browser bug into a higher-value foothold on endpoints that are frequently trusted and widely deployed.

See the vendor record in the CVE Program for the canonical identifier and the CISA Known Exploited Vulnerabilities Catalog for the current exploitation status and response expectation.

What the vulnerability changes in practice

This is a memory-safety weakness in Chromium’s GPU component, so the practical concern is browser compromise through crafted content rather than a traditional server-side break-in. The remote attacker model matters because the initial entry point can be a malicious or compromised HTML page, but exploitation still depends on reaching the vulnerable browser state and successfully chaining the overflow into sandbox escape.

That combination changes the defensive posture. Browser hardening, rapid patching, and limiting exposure to untrusted web content become directly relevant, because the exploit path is tied to normal user browsing rather than a special application workflow. In practice, the main question is not whether the browser can crash, but whether an attacker can use the crashable condition to gain meaningful execution beyond the renderer.

The weakness itself also fits the broader memory-corruption pattern behind many actively exploited browser CVEs. Teams should treat it as part of the same class of issue that often appears in exploit chains, where the browser bug is only one stage in a multi-step intrusion.

For a deeper view of the weakness class itself, see the CWE Top 25 Guide for the memory-safety and buffer-overflow patterns that recur in real-world exploitation.

What to verify, defer, and hunt for

If patching is delayed, verify whether the affected Chromium build is installed on endpoints that regularly open untrusted content, use exposed web apps, or support privileged browsing workflows. Also check whether browser isolation, extension controls, and managed update channels are actually enforced, because those controls can materially change blast radius even when the vulnerable code remains present.

Where remediation cannot happen immediately, the next best step is exposure reduction and compromise hunting. Review browser telemetry, crash reports, and endpoint detections for signs that the renderer or GPU process behaved abnormally before the patch window closed. If a user opened a suspicious page around the time of possible exposure, assume the browser session may have been part of the attack chain and validate adjacent endpoints rather than only the browser process itself.

For a practical response sequence, the Zero-Day and Exploited Vulnerabilities Guide covers emergency mitigation, compromise assessment, and post-patch hunting, while the Vulnerability Management Guide covers KEV-driven prioritisation and verification.

Risk and Threat Considerations

Browser exploitation is especially dangerous because it sits on a high-frequency trust boundary. A successful exploit can convert ordinary web browsing into a foothold for sandbox escape, which makes the vulnerable browser a bridge into the endpoint rather than just a client-side defect.

Failure mechanism: A crafted page drives a renderer-side memory corruption condition and uses it to escape Chromium’s sandbox, reducing the protection normally provided by process isolation.

Impact: Attackers can move from web content exposure to broader endpoint compromise, which may enable credential theft, session abuse, or follow-on execution on a user workstation.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, 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 makes rapid vulnerability prioritization and remediation central here.
Recommendation — Prioritise KEV-listed browser flaws for immediate remediation and verify closure on exposed endpoints.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The question hinges on confirming exposure and tracking an actively exploited CVE.
	SI-2 — Flaw Remediation	Actively exploited browser flaws require timely correction and controlled exception handling.
Recommendation — Scan for the vulnerable Chromium build and validate remediation across all affected assets. Apply the fix or mitigation quickly and document any temporary exception until patched.
OWASP ASVS	V13 — Configuration	Browser hardening and managed update posture affect how exploitable the flaw is on endpoints.
	V15 — Secure Coding and Architecture	Heap overflow exploitation is a software memory-safety issue that maps to secure architecture concerns.
Recommendation — Harden browser configuration and enforce rapid update channels on managed endpoints. Use memory-safe design and exploit-mitigation testing to reduce browser-side corruption risk.
MITRE ATT&CK	T1189 — Drive-by Compromise	The exploit path uses a crafted web page as the initial attack vector.
	T1203 — Exploitation for Client Execution	The flaw is a client-side execution issue that can trigger from malicious content.
	T1068 — Exploitation for Privilege Escalation	Sandbox escape is a privilege boundary break that can increase attacker control.
Recommendation — Hunt for web-delivered compromise chains and correlate browser telemetry with endpoint alerts. Monitor for exploit-triggered client execution and investigate suspicious browser crashes. Treat sandbox escape indicators as privilege-escalation events and scope the host for follow-on activity.

Practitioner Guidance

What to verify: Confirm which Chromium channels, embedded browsers, and third-party products ship the affected engine, because browser exposure is often broader than the main desktop browser install. Treat any endpoint that cannot update quickly as a short-term exception that needs compensating controls.

Decision rule: If the device can reach untrusted web content and the browser cannot be patched immediately, prioritise temporary exposure reduction, user targeting, and hunting over waiting for symptom-driven detection. If the browser is used in a privileged workflow, escalate the urgency further because a renderer escape can have outsized impact.

Practitioner takeaway: For KEV-listed browser flaws, the real security question is not whether exploitation is technically possible, but whether your fleet can still be reached before the update and hunting actions are complete.

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