Is CVE-2023-2136 (Google Chrome Skia Integer Overflow) being exploited in the wild?

Yes. CISA added CVE-2023-2136 to its Known Exploited Vulnerabilities catalogue on 21 April 2023, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Google Chromium Skia contains an integer overflow vulnerability that allows a remote attacker, who has compromised the renderer process, to potentially perform a sandbox escape via a crafted HTML page.

What “exploited in the wild” means for CVE-2023-2136

For this CVE, “in the wild” means there is evidence of real attacker use, not just a proof of concept or theoretical risk. CISA’s KEV listing is the operational signal most defenders use to treat the issue as actively exploited and to prioritise it ahead of lower-confidence findings.

The key question is not whether the weakness exists, but whether your Chrome deployment is still exposed to the version and process conditions that make exploitation possible. For browser issues, that usually means the browser itself, the update cadence, and whether endpoint controls can verify that managed browsers are actually current.

When a browser vulnerability is actively exploited, the blast radius is broader than a single tab or URL. A successful exploit can turn a crafted page into a foothold inside the renderer sandbox, which is why browser hardening and containment matter even when users are already behind a proxy or secure web gateway.

Why this Chrome Skia flaw matters operationally

The vulnerability sits in a rendering component, so the user-facing trigger can look ordinary even when the attack path is not. That makes it easy to underestimate, especially in environments that assume “browser security” is only about phishing or malicious downloads. In practice, a web page can become the delivery vehicle for code-path abuse inside the browser.

Because the flaw is tied to a renderer compromise path, defenders should think about browser isolation, extension control, and policy enforcement together. A browser that is nominally managed but allowed to run risky extensions, stale builds, or unsupported profiles will often be the one that fails first.

If you need a broader controls lens for this class of issue, the Enterprise Browser and Browser Security Guide is the most directly relevant NHIMG navigation point for secure browser policies, isolation, and browser hardening.

How teams should confirm exposure and respond

Start by inventorying every Chrome channel in use, including managed desktops, VDI images, shared workstations, and any embedded browser components in downstream tools. If you cannot verify the running build and update source, you do not really know whether the environment is protected against a KEV-listed issue.

Prioritise the vendor advisory and the KEV catalogue for version and remediation details, then align your response to the browser fleet that is actually reachable by end users. The most useful evidence is not a generic patch report, but a confirmation that the vulnerable browser population has been updated and that update enforcement is working.

If patching is delayed, reduce exposure by tightening browser policy, restricting high-risk browsing paths, and increasing monitoring for suspicious renderer crashes, unusual browser child processes, or sudden shifts in endpoint telemetry. For an exploited issue, that temporary control set is a bridge, not a substitute for remediation.

For teams that need a second opinion on prioritisation, Zero-Day and Exploited Vulnerabilities Guide explains the practical response pattern for KEV-listed flaws, and Vulnerability Management Guide covers how to sequence remediation, exceptions, and verification.

Risk and Threat Considerations

Actively exploited browser flaws create a fast-moving exposure problem because the attack surface is ubiquitous and the trigger can be a normal-looking web interaction. Once a browser renderer is compromised, the attacker may be able to move from content execution toward sandbox escape and then into credential theft, session abuse, or follow-on payload delivery.

Failure mechanism: An attacker uses crafted web content to exercise the vulnerable Skia code path after compromising the renderer process, which can turn a memory corruption bug into a sandbox escape path.

Impact: The practical impact is remote compromise potential on any endpoint that still runs an exposed build, with downstream risk to user sessions, browser-stored data, and broader endpoint trust.

Standards & Framework Alignment

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

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

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.AM-01 — Physical devices and systems within the organization are inventoried	Browser exposure response depends on knowing which endpoints run Chrome.
	PR.AA-05 — Assets are managed commensurate with risk	Managed browsers need enforced update and hardening controls for active exploitation risk.
Recommendation — Inventory all endpoints running the affected browser and verify update coverage. Enforce browser policy and update controls on all managed endpoints.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation requires prioritised remediation and validation.
Recommendation — Prioritise remediation of KEV-listed browser vulnerabilities and verify closure.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Actively exploited browser flaws require rapid remediation and update verification.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation requires scanning and validation of affected browser builds.
Recommendation — Accelerate patch deployment and confirm vulnerable builds are removed. Scan for affected browser versions and validate remediation across the fleet.

Practitioner Guidance

What to verify: Confirm that your fleet inventory covers all browser channels, not just standard managed desktops. Pay special attention to roaming users, test rings, unmanaged profiles, and any endpoints where browser updates can lag behind central policy.

Decision rule: If the browser build cannot be verified quickly, treat the endpoint as exposed until proven otherwise. If a device has repeated browser instability, suspicious page load behavior, or signs of post-exploitation activity, escalate to compromise assessment rather than assuming patching alone is enough.

What good looks like: Managed browsers update automatically, policy enforcement is measurable, and endpoint telemetry can show that the vulnerable population has actually moved off the affected build.

Practitioner takeaway: For a KEV-listed browser flaw, the right unit of work is the exposed browser population, not the individual vulnerability record.