How do you patch or mitigate CVE-2023-2136 (Google Chrome Skia Integer Overflow)?

CISA’s required action for CVE-2023-2136 is to apply updates per vendor instructions. In practice, find every instance of Google Chromium Skia in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What it takes to fix CVE-2023-2136 in a real estate

Start with inventory, not with a single browser window. You need to identify every Chrome-based build, embedded Chromium instance, and product that ships the Skia graphics stack, then verify which systems are actually receiving vendor updates. For a vulnerability that is already being exploited, the practical question is whether the affected software can be updated fast enough everywhere it exists.

The cleanest fix is to follow the vendor update path and confirm that the update really reached the endpoint or application image. For browser fleets, that usually means managed browser policy, enforced update cadence, and a post-update check that the installed version matches the vendor’s security release channel. For embedded Chromium, the repair path is usually slower because the browser engine is wrapped inside another product and may require a full vendor rebuild.

Where updates are blocked, mitigation is about reducing reach rather than pretending the risk is gone. If the vulnerable instance cannot be fixed immediately, remove direct internet exposure, isolate it from untrusted content, and take it out of service if the business cannot accept the exposure window. That is especially important for systems where browser rendering is part of a high-trust workflow, because a browser exploit often becomes the first step in broader compromise. Enterprise Browser and Browser Security Guide is useful here because browser hardening, isolation, and extension control are the same controls that reduce the blast radius while you wait for remediation.

How to confirm exposure and verify the fix

Patch validation should be evidence-based. Confirm which systems run Google Chromium or products built on it, then check the vendor advisory, the CISA KEV catalog, and your own software inventory to make sure no shadow copies remain in containers, golden images, VDI pools, or unmanaged endpoints. If the affected component is part of a larger application, do not stop at the application brand name, check the underlying runtime or bundled browser engine too.

After applying the update or mitigation, verify the installed build and test the affected workflow, not just the package manager output. In practice, a browser fix can fail silently when an enterprise build is pinned, an update service is disabled, or an embedded component ships on its own release train. A second verification pass should confirm that any compensating control, such as network isolation or disabled exposure, actually remains in place after reboot, redeploy, or autoscaling.

For prioritisation, treat known exploitation as a force multiplier. CISA Known Exploited Vulnerabilities Catalog is the operational reference for whether a CVE is being actively abused, while NIST National Vulnerability Database helps you tie the record back to the product and vulnerability record in your own tracking. If you need to decide what to patch first across a large backlog, exploitability data from FIRST EPSS can support the queue, but it should not override a KEV-listed item.

What to do after patching, or when patching must wait

When patching is delayed, assume the exposed system may already have been touched. Review browser, system, and proxy logs for unusual downloads, suspicious redirects, unexpected child processes, or signs that a user session was used as the foothold. If the affected system handles sensitive data or has elevated access, also check for secondary actions that would indicate the browser exploit was only the entry point.

The post-fix check is not just about malware hunting. You also want to know whether the vulnerable instance exposed credentials, sessions, or other security material that could still be reused after the browser is updated. If there is any sign of compromise, rotate the relevant credentials, invalidate sessions where applicable, and review adjacent systems that may have trusted the same browser host or user context. The Vulnerability Management Guide is a useful companion for building the verification and exception workflow around that response.

Risk and Threat Considerations

Actively exploited browser flaws are dangerous because they combine easy exposure with broad user reach. If the vulnerable component is internet-facing or regularly processes untrusted web content, an attacker may only need one successful delivery path to gain code execution or a reliable foothold on the endpoint.

Failure mechanism: Integer overflow weaknesses can corrupt memory handling inside the rendering stack, which can turn ordinary page processing into a crash or arbitrary code execution path when malicious content exercises the vulnerable code.

Impact: The practical impact is endpoint compromise, session theft, follow-on credential access, and possible lateral movement if the browser host has access to internal applications or authenticated workflows.

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 CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Addresses timely identification and remediation of exploitable software flaws.
Recommendation — Prioritise KEV-listed browser vulnerabilities for immediate remediation and verify closure in your vulnerability workflow.
NIST CSF 2.0	PR.IP-12 — Vulnerability management is performed	Applies because the question is about patching a known exploited vulnerability.
	RS.MI-01 — Incidents are contained	Relevant when mitigation must substitute for immediate patching and exposure must be contained.
Recommendation — Track the Chrome/Chromium exposure through your vulnerability management process until remediation is verified. Contain exposed systems by removing internet reachability or taking them out of service until the fix is applied.
MITRE ATT&CK	T1203 — Exploitation for Client Execution	Browser exploitation commonly begins with malicious content delivered to a client application.
Recommendation — Hunt for client-side exploitation indicators in browser and endpoint telemetry after remediation.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Directly governs patching and mitigation of software vulnerabilities.
Recommendation — Apply vendor updates or approved mitigations and confirm affected assets are remediated.

Practitioner Guidance

What to prioritise: Patch the externally reachable or highest-privilege Chrome-based instances first, then move to embedded Chromium products and managed browser fleets. If a system cannot be patched quickly, treat exposure removal as a temporary control, not a final state.

What to verify: Confirm the vendor update landed on the actual runtime, not just the package repository or image source, and check for the same vulnerable engine inside products that bundle Chromium. Afterward, validate that logging still captures the evidence you would need if the flaw was abused before remediation.

Practitioner takeaway: For an actively exploited browser vulnerability, the real decision is whether you can eliminate exposure fast enough everywhere the engine exists; if not, reduce reach first, then prove the update and hunt for pre-existing compromise.