Is CVE-2022-1096 (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-1096 to its Known Exploited Vulnerabilities catalogue on 28 March 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.

What it means for a browser engine flaw to be actively exploited

CVE-2022-1096 is not just a theoretical Chromium issue. Once a vulnerability appears in CISA’s Known Exploited Vulnerabilities catalogue, the practical question shifts from “is this serious?” to “where are we exposed, and how fast can we reduce blast radius?” For browser-engine bugs, the exposed surface is often broad because the attack trigger can be a normal-looking web page.

For this class of flaw, the highest-value first check is whether any user population still runs the affected browser family and whether managed update channels are actually enforced. A browser exploit is especially attractive because it can begin with ordinary user interaction, then leverage the browser’s rendering and JavaScript processing path to reach memory corruption.

That is why CISA KEV is useful operationally. It is a confirmed exploitation signal, not a scoring opinion, and it should move the vulnerability into your highest-priority remediation queue. Where browser controls are weak, the exploit path is often less about one missing patch and more about inconsistent fleet management, delayed restarts, or unmanaged endpoints that still browse the public internet.

Why Chromium V8 type confusion is a dangerous attack path

Type confusion in a browser engine means the code makes the wrong assumption about an object’s type or layout. In a JavaScript engine, that can turn an apparently valid script operation into heap corruption, which may then be used for code execution or a browser compromise chain. The attacker does not need privileged network access if they can deliver a crafted page that the victim opens.

The material security issue is not only the bug itself, but the trust boundary it crosses. Browsers sit at the edge of user activity, identity sessions, and enterprise application access, so a successful compromise can expose tokens, cookies, and active sessions even when the original payload is “just” web content. That makes browser-engine exploitation a common starting point for broader account and endpoint compromise.

Because the vulnerability can be triggered remotely, detection is usually indirect. You are more likely to see suspicious browser crashes, unexpected renderer instability, or a chain that follows exploitation into post-compromise activity than a clean alert naming the CVE itself.

What to do when patching cannot happen immediately

If you cannot remediate all endpoints at once, reduce exposure by tightening browser update enforcement, isolating higher-risk browsing roles, and limiting the number of devices allowed to reach sensitive web applications from unmanaged browsers. For users with privileged access, separate administrative browsing from everyday browsing and treat browser compromise as a credential exposure event, not only an endpoint event.

Use Enterprise Browser and Browser Security Guide to align browser hardening, extension control, isolation, and credential theft reduction with your endpoint policy. For vulnerability operations, Vulnerability Management Guide is the better reference for confirming scope, prioritising exploitation signals, and tracking remediation SLAs.

When patching must wait, the fallback is not “accept the risk and monitor.” It is to constrain the most likely attack path: reduce exposure to untrusted browsing, force sign-out or credential rotation if compromise is suspected, and verify whether the browser is used to reach admin portals, cloud consoles, or internal applications with standing sessions.

Risk and Threat Considerations

Active exploitation of a browser-engine CVE creates an immediate exposure problem because the initial access path can be a normal web visit, not a targeted exploit against a hardened server. The same weakness can be reused across large fleets, which makes browser flaws attractive for opportunistic exploitation and for follow-on compromise of sessions and credentials.

Failure mechanism: A crafted HTML page or malicious web content drives the V8 engine into type confusion, leading to heap corruption and potential execution in the browser context.

Impact: Victims can lose browser sessions, saved authentication material, or endpoint integrity, and the compromise may become a launch point for account takeover or further malware delivery.

Standards & Framework Alignment

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

CIS Controls v8, NIST CSF 2.0, 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	CVE-2022-1096 is a known-exploited vulnerability needing rapid identification and remediation.
Recommendation — Prioritise this browser CVE in continuous vulnerability management and track remediation to closure.
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	KEV listing changes priority and requires risk-based remediation decisions.
Recommendation — Place KEV-listed browser flaws into your highest-risk remediation workflow.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Browser engine vulnerabilities require prompt flaw remediation and update enforcement.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation depends on finding affected endpoints and unmanaged browsers.
Recommendation — Patch the browser promptly and verify deployed systems actually receive the fix. Scan for affected browser installations and track unremediated endpoints to closure.
OWASP ASVS	V15 — Secure Coding and Architecture	The flaw is a browser-engine memory corruption issue that maps to secure architecture and robustness.
Recommendation — Use secure-engineering controls to reduce memory-corruption exposure in browser-facing code.

Practitioner Guidance

What to verify: Confirm that the vulnerable browser family is not merely installed, but actively updated on every managed workstation and that users cannot defer restart long enough to leave known-exploited code in place. For browsers used to access privileged systems, verify whether session persistence or saved credentials increase the blast radius of a compromise.

Decision rule: If a browser vulnerability is in KEV, treat it as an exposure-management issue first and a technical patching issue second. Patch as quickly as possible, and if remediation is delayed, escalate any system that can browse sensitive applications, hold privileged sessions, or store reusable credentials.

Practitioner takeaway: With browser-engine exploitation, the real risk is not only code execution, but the trusted session and credential context that execution can inherit, so patch speed and exposure reduction matter more than post-event cleanup.

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