CVE-2022-1364 is a type confusion vulnerability in Google Chromium V8. CISA added it to the Known Exploited Vulnerabilities catalogue on 15 April 2022, which means attackers have used it in real attacks. Google Chromium V8 Engine contains a type confusion vulnerability that allows a remote attacker to potentially exploit heap corruption via a crafted HTML page.
What Makes This Vulnerability Dangerous
CVE-2022-1364 is dangerous because it affects the browser engine that interprets untrusted web content. A crafted page can trigger memory corruption in V8, which means a simple visit to a malicious site can become a reliable entry point for code execution or follow-on compromise.
For browser engine flaws, the practical concern is not only the defect itself but the trust boundary it breaks. Web content is supposed to be isolated from the underlying system, so a type confusion bug undermines that assumption and can let hostile JavaScript influence memory in ways the engine was never meant to allow.
How Organisations Check Exposure
Exposure starts with knowing where Chromium-based browsers and embedded Chromium runtimes are used across desktops, VDI pools, kiosks, managed devices, and any products that ship the V8 engine. Teams should then compare that inventory against vendor advisories and the CVE Program record, plus the NIST National Vulnerability Database, to confirm whether the environment still includes affected builds.
Internet exposure also matters. Browsers are directly exposed to hostile input by design, so even well-managed estates can be at risk if users are allowed to browse untrusted sites or if embedded browser components sit inside applications that process external HTML or web content.
Because CISA placed this CVE in the KEV catalogue, organisations should treat it as a known exploited issue and prioritise verification over assumption. For a broader remediation workflow, NHIMG’s Vulnerability Management Guide is useful for scoping assets, prioritising by exploitability, and validating that exposure has actually been removed.
Remediation and Compensating Controls
The preferred fix is to apply the vendor’s update path for the affected Chromium or embedded V8 build, but remediation should not stop at patching alone. Organisations should reduce exposure while patching is in progress by limiting untrusted browsing, tightening browser extension policy, and narrowing where the vulnerable engine is available.
Where immediate patching is not possible, compensating controls should focus on reducing the blast radius of a successful exploit. That usually means stronger endpoint hardening, least-privilege execution, application containment, and careful control of browser-based access to sensitive internal resources.
For teams that need a control-catalogue view of hardening and containment, NIST SP 800-53 Rev. 5 Security and Privacy Controls provides the broad control families typically used to support patch governance, system integrity, and protective configuration.
Detection and Post-Compromise Review
Detection for browser engine exploitation is often indirect because the initial trigger happens in a user’s browser session. Security teams should look for suspicious browser crashes, unusual child processes, unexpected downloads, and post-exploitation activity that follows a user visiting a malicious page.
After patching, review whether the vulnerable browser instance was already used as an initial access vector. A successful exploit can still leave behind malicious files, altered settings, stolen session material, or secondary payloads even after the original flaw is fixed.
For adversary behaviour, the MITRE ATT&CK Enterprise Matrix is useful for mapping follow-on activity such as initial access, execution, persistence, and defense evasion when a browser exploit is part of a larger intrusion chain.
Risk and Threat Considerations
Browser engine vulnerabilities are attractive because they sit at the boundary between trusted software and hostile web content. When exploitation succeeds, the attacker may gain a foothold through something users are expected to open every day, which makes the issue especially dangerous in environments with broad web access.
Failure mechanism: Type confusion can let the engine mis-handle memory objects, creating heap corruption that an attacker can shape into code execution or sandbox escape attempts.
Impact: A compromised browser session can become a launch point for credential theft, malware delivery, or broader endpoint compromise, especially if the user has access to sensitive internal services.
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 NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1203 — Exploitation for Client Execution | Browser-engine type confusion is a client-side exploitation path. |
| Recommendation — Map browser exploit telemetry to T1203 and investigate hostile web content leading to execution. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | This CVE requires timely vulnerability remediation and verification. |
| SI-3 — Malicious Code Protection | Browser exploitation is often paired with malicious payload delivery and execution. | |
| CM-2 — Baseline Configuration | Managing vulnerable browser deployments depends on controlled software baselines. | |
| Recommendation — Track and remediate the affected browser build under SI-2 and confirm exposure is removed. Strengthen malicious code protections on endpoints that browse untrusted content. Enforce approved browser baselines so vulnerable builds are not left in production. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Known exploited CVEs require inventory, prioritisation, and verified remediation. |
| Recommendation — Prioritise this KEV-listed browser flaw in continuous vulnerability management. | ||
Practitioner Guidance
Why practitioners should care: Treat exploited browser-engine CVEs as high-priority exposure items, not generic patch backlog entries. The security concern is immediate user reachability, not just the technical severity of the flaw.
What to watch for: Prioritise devices and applications that embed Chromium or expose users to untrusted HTML content, then verify remediation through asset-based checks rather than relying on browser version assumptions alone.
Practitioner takeaway: For browser CVEs like this one, the right question is not only whether a patch exists, but whether the vulnerable engine has been removed from every place users or applications can still reach.