Is CVE-2022-3723 (Google Chromium V8 Type Confusion) being exploited in the wild?

Yes. CISA added CVE-2022-3723 to its Known Exploited Vulnerabilities catalogue on 28 October 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 KEV changes the answer for CVE-2022-3723

CISA’s KEV listing is the practical signal that this issue is not just theoretical. For defenders, the key question is no longer whether the browser flaw can be weaponised, but whether any Chromium-based browsers in your estate were exposed during the active exploitation window and whether user traffic could have reached a crafted page.

That shifts triage away from abstract vulnerability review and toward exposure confirmation. If the browser family is present, version inventory, endpoint ownership, and internet-facing usage patterns matter more than a generic patch queue. CISA’s catalogue is the first place to verify exploitation status and track required remediation urgency.

For broader patch prioritisation around exploited issues, the Zero-Day and Exploited Vulnerabilities Guide explains how to handle KEV-listed weaknesses when exploit activity is already established, while the Vulnerability Management Guide is useful when you need to turn KEV status into a repeatable prioritisation workflow.

What exploitation in the wild means operationally

“Exploited in the wild” means the flaw has moved beyond lab reproduction and proof-of-concept reporting. In practice, that means a browser user may be compromised simply by loading malicious or booby-trapped content, so the security problem is not limited to a server-side patch cycle. Browser exploitation also tends to be opportunistic, which makes broad exposure much more relevant than a narrow target list.

For this kind of issue, the main operational concern is silent compromise. A successful browser exploit can give an attacker code execution or memory corruption primitives that are then used to stage follow-on payloads, steal data, or establish persistence through the endpoint. That is why browser telemetry, endpoint detection, and recent history review become part of the response, not just patch deployment.

The CVE Program remains the authoritative reference for the vulnerability record itself, and the NIST National Vulnerability Database is the most useful place to cross-check the record and related metadata when you are building an internal tracking workflow.

What to do when patching or browser upgrades are delayed

If immediate remediation is not possible, treat the browser as a high-risk execution surface. The practical objective is to reduce the chance of reaching a malicious page and to reduce the chance that a successful exploit can turn into a full endpoint compromise. That usually means narrowing browsing exposure, strengthening browser hardening, and increasing scrutiny on suspicious web content rather than relying on user awareness alone.

Where browsers are centrally managed, controls around extension policy, download restrictions, isolation, and telemetry matter because they reduce the usefulness of a single successful exploit. The goal is to make exploitation harder to convert into token theft, credential theft, or lateral movement. In parallel, review whether the affected browser is used for privileged workflows, because privileged browsing materially increases the blast radius.

The Enterprise Browser and Browser Security Guide is the natural internal companion here because it covers browser hardening, isolation, and extension control. For external prioritisation support, FIRST EPSS can help you compare this issue against other active vulnerabilities when you need a risk-based queue.

Risk and Threat Considerations

A KEV-listed browser flaw carries real exposure because the exploit path is easy to deliver and hard for users to recognise. The danger is not only initial compromise, but also what the attacker can do after the browser process is taken over, especially on endpoints that hold active sessions, saved credentials, or access to internal applications.

Failure mechanism: A crafted page triggers the chromium v8 type confusion bug, leading to heap corruption and potential arbitrary code execution or adjacent compromise on the endpoint.

Impact: Attackers may gain a foothold through normal browsing, then pivot to session theft, data access, malware delivery, or broader enterprise compromise if the endpoint is trusted or overprivileged.

Standards & Framework Alignment

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

NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Browser CVEs require timely remediation and exposure tracking.
	RA-5 — Vulnerability Monitoring and Scanning	Confirm where the vulnerable browser exists and whether exposure is still present.
	AU-6 — Audit Review, Analysis, and Reporting	Endpoint and browser telemetry help detect signs of compromise after exploitation.
Recommendation — Prioritise remediation of KEV-listed browser flaws and track overdue fixes. Scan for affected browser installations and validate current exposure. Review logs and endpoint telemetry for suspicious browser activity.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed browser issues fit continuous prioritisation and remediation workflows.
	CIS-10 — Malware Defenses	Browser exploitation often leads to malicious payload delivery or follow-on malware.
Recommendation — Continuously prioritise and remediate exploited browser vulnerabilities. Strengthen malware defenses on endpoints that can reach hostile web content.

Practitioner Guidance

What to verify: Confirm which endpoints run affected Chromium-based browsers, which users browse untrusted content, and which systems rely on those browsers for privileged access. Browser exposure is materially more serious where the same machine is used for admin consoles, cloud portals, or sensitive internal applications.

Decision rule: If the browser is present on a managed endpoint, treat KEV status as a patch-or-mitigate-now event, not a routine backlog item. If patching must wait, reduce exposure first by limiting browsing scope, isolating higher-risk browsing, and reviewing recent endpoint activity for signs of compromise.

Practitioner takeaway: For actively exploited browser CVEs, the right question is not only whether the patch exists, but whether any endpoint could have reached malicious content before remediation and whether that endpoint holds credentials or sessions worth stealing.