Is CVE-2022-2856 (Google Chromium Intents Insufficient Input Validation) being exploited in the wild?

Yes. CISA added CVE-2022-2856 to its Known Exploited Vulnerabilities catalogue on 18 August 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Google Chromium Intents contains an insufficient validation of untrusted input vulnerability that allows a remote attacker to browse to a malicious website via a crafted HTML page.

How KEV status answers the “exploited in the wild” question

For a CVE like this, the practical answer is not inferred from the weakness description alone. The key signal is CISA’s KEV listing, because KEV inclusion means CISA has evidence of active exploitation and expects organisations to treat the issue as more than theoretical. That makes exposure checking and prioritisation more important than debating exploitability in the abstract.

Anyone running Chromium-based browsers or embedded browser components should verify whether the vulnerable version is present anywhere in the estate, including managed desktops, VDI images, kiosk systems and software that bundles Chromium. Browser exploitation often matters because a malicious page can be enough to trigger the flaw, so the attack surface is broader than just direct software installs.

Related browser hardening guidance is covered in NHIMG’s Enterprise Browser and Browser Security Guide, which is useful when you need to reduce exposure to malicious pages, extensions and browser-based attacks.

What the vulnerability means operationally

The underlying issue is insufficient validation of untrusted input in Chromium Intents, which means the flaw sits in how the browser interprets data supplied by external content. In practice, that can turn an apparently ordinary web visit into a security event if a crafted page can drive the browser into unsafe behaviour. The operational concern is not only the browser itself, but the users, sessions and workflows reachable through it.

Because the vulnerability is tied to untrusted input handling, the most useful question is where malicious content can reach Chromium in your environment. That includes ordinary browsing, internal web apps, links opened from chat or email, and any workflow where a browser is the default renderer for content. If those paths exist, treat browser hardening and patching as part of core endpoint risk reduction, not as an optional hygiene task.

Secure input handling is a foundational control theme in Secure Coding Guide, and the broader weakness pattern is also well represented in CWE Top 25 Guide when you need to understand how insufficient validation becomes exploitable.

What to do when patching cannot happen immediately

If you cannot patch at once, focus on exposure reduction and compromise checking. Restrict access to high-risk browsing contexts, limit untrusted content sources, review browser isolation options, and inspect whether any suspicious pages were recently opened by affected users. Where the browser is part of a privileged or high-value workflow, assume the blast radius may include credentials, sessions or downstream access rather than only the browser process itself.

The right response sequence is to confirm exposure, apply the vendor fix as soon as possible, and then look for signs that the flaw was already used. That is the same operating model NHIMG recommends for Zero-Day and Exploited Vulnerabilities Guide, because active exploitation changes the priority from routine patching to urgent containment and verification.

For vulnerability prioritisation and exception handling, Vulnerability Management Guide is the best operational companion for deciding how fast to move, what evidence to retain and how to handle remediation delays.

Risk and Threat Considerations

When a browser CVE is already in KEV, the main risk is not just code execution or browser crash behaviour, but reliable attacker use of a common user action path. A crafted page can reach many endpoints quickly, which makes browser flaws attractive for broad initial access, drive-by delivery and follow-on session theft.

Failure mechanism: Untrusted web content is parsed or acted on without sufficient validation, allowing hostile input to steer the browser into unsafe behaviour before the user realises anything is wrong.

Impact: Successful exploitation can expose users, sessions and browser-resident data, and it can create a foothold for broader compromise if the browser is the first trusted application reached by the attacker.

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 SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes rapid vuln triage and remediation central.
Recommendation — Prioritise and remediate KEV-listed browser flaws on an urgent patch timeline.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This CVE requires prompt flaw remediation once exposure is confirmed.
	RA-5 — Vulnerability Monitoring and Scanning	You need scanning to find every Chromium exposure path before remediating.
	SI-10 — Information Input Validation	The vulnerability is an untrusted-input validation failure in Chromium Intents.
Recommendation — Apply SI-2 to track, test, and deploy the browser fix quickly. Use RA-5 to identify all affected browser deployments and embedded Chromium instances. Reinforce SI-10 expectations in code paths that process external browser input.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	KEV-listed exploitation calls for formal vulnerability handling and remediation tracking.
Recommendation — Track the CVE through your technical vulnerability process until exposure is removed.

Practitioner Guidance

What to verify: Confirm where Chromium is embedded, not just where the browser is installed. Many organisations miss packaged applications, remote work images and alternate channels where the same engine is present but not separately tracked.

Decision rule: If a vulnerable browser instance can reach sensitive web properties, treat it as a priority remediation item even if exploitation has not been observed locally. Active KEV status is enough to justify urgent action.

Practitioner takeaway: For browser CVEs, “exploited in the wild” should trigger exposure confirmation, urgent patching and compromise review in the same workstream, because the business risk comes from how quickly ordinary web access can become a real attack path.