Is CVE-2022-1364 (Google Chromium V8 Type Confusion) 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-1364 to its Known Exploited Vulnerabilities catalogue on 15 April 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Google Chromium V8 Engine contains a type confusion vulnerability that allows a remote attacker to potentially exploit heap corruption via a crafted HTML page.

How CISA’s KEV Listing Confirms Active Exploitation

CISA’s Known Exploited Vulnerabilities catalogue is the practical indicator that matters here: if a CVE appears there, CISA has judged that it is being actively exploited and should be treated as more than a theoretical flaw. For CVE-2022-1364, the operational question is not whether exploitation is possible, but whether any Chromium-based browsers in your fleet are still exposed and reachable from users.

That means confirmation starts with inventory, not with severity scoring. Identify every managed desktop, VDI image, kiosk, and embedded browser runtime that can execute Chromium V8, then map the browser channel and patch state to your exposure window. The relevant source of truth is the vendor advisory and the KEV catalogue, not a copied version number in a ticket.

When a browser engine bug is already on KEV, the response priority is usually driven by reachability and user exposure, especially where users can visit arbitrary web content or where browser-controlled automation is allowed to run. A small exposed population can still be high risk if it is internet-facing or used for sensitive workflows.

What the V8 Type Confusion Bug Changes Operationally

A type confusion flaw in a JavaScript engine is dangerous because attacker-controlled content can push the engine into an unsafe memory state. In this case, the direct answer already states that a crafted HTML page can trigger heap corruption, which is why browser exploitation is often an entry point for code execution, sandbox escape chaining, or follow-on credential theft.

For practitioners, the key implication is that browser exploitation is usually user-mediated. Security teams should assume that successful exploitation may begin with ordinary web traffic, malicious ads, compromised sites, or a lure delivered through a trusted workflow. That makes web filtering, browser hardening, and rapid patch adoption materially relevant even when the vulnerable component is not a server.

Enterprise Browser and Browser Security Guide is the right internal starting point when you need the browser-hardening controls that reduce the blast radius of engine exploits.

What to Do If Patching Is Delayed

If immediate patching is blocked, treat the issue as a temporary exposure management problem. Reduce browser attack surface by limiting internet access where possible, tightening extension policy, disabling unnecessary script-bearing features in high-risk environments, and prioritising the most exposed user groups first. Browser vulnerabilities are hardest to absorb when users have broad web reach and no compensating controls.

Use CISA KEV as the trigger for compensating action, not as a postmortem checklist. If you cannot patch all endpoints at once, segment the rollout by business criticality, exposure, and privilege. Managed browsers used by administrators, finance users, developers, or anyone handling sensitive sessions should move ahead of low-risk endpoints.

Also validate whether the browser is embedded inside another product or bundled into an enterprise image that may not be covered by your normal patch dashboards. That is a common miss when exploitation affects a browser engine rather than a standalone browser package.

Risk and Threat Considerations

This is a live-exploitation browser flaw, so the main risk is that ordinary user browsing becomes a remote attack path into managed endpoints. Because the trigger can be a crafted page, exposure can exist even on systems that are otherwise well controlled, and compromise may be difficult to distinguish from routine browser activity.

Failure mechanism: The attacker supplies content that drives V8 into type confusion, corrupts heap state, and may then chain the result into code execution or deeper browser compromise.

Impact: A successful exploit can expose user sessions, local data, and adjacent enterprise access paths, especially where the browser is trusted for authentication or internal application use.

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 CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited browser flaws require rapid identification and remediation of exposed endpoints.
	CIS-4 — Secure Configuration of Enterprise Assets and Software	Browser hardening and extension policy reduce exploitability of web-delivered attacks.
Recommendation — Prioritise scanning and remediation for exposed Chromium-based browsers. Harden browser settings and restrict unnecessary extension and script exposure.
NIST CSF 2.0	PR.PS-02 — Software, firmware, and information are maintained consistent with policies, procedures, and agreements	Prompt patching of an actively exploited browser component is a software maintenance control.
	ID.RA-01 — Asset vulnerabilities are identified and documented	The question depends on identifying whether vulnerable Chromium instances remain exposed.
	DE.CM-09 — Computing hardware, software, and systems are monitored to identify cybersecurity events	Exploited browser flaws warrant monitoring for compromise indicators after exposure is confirmed.
Recommendation — Accelerate deployment of the browser fix across exposed assets. Maintain an accurate inventory of affected browser installations and exposure. Monitor endpoints for signs of browser exploitation and post-compromise activity.

Practitioner Guidance

What to verify: Confirm which endpoints are actually running vulnerable Chromium-based builds, not just which ones appear in software inventory. Browser exploits often persist because patch evidence is fragmented across managed devices, personal browsers used for work, and embedded runtimes.

Decision rule: If a system can browse untrusted content and still shows unpatched Chromium exposure, treat it as a priority remediation target even if the asset is not a server or a privileged workstation. If patching must wait, constrain access and reduce the number of users who can reach the affected browser surface.

Practitioner takeaway: For actively exploited browser CVEs, the fastest risk reduction comes from proving exposure, reducing reachability, and closing the patch gap in the highest-value user paths first.

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