Yes. CISA added CVE-2023-6345 to its Known Exploited Vulnerabilities catalogue on 30 November 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 malicious file.
What “exploited in the wild” means for CVE-2023-6345
CISA’s KEV listing is the practical signal that matters here: when a vulnerability is added, CISA is saying there is reliable evidence of active exploitation, not just theoretical risk. For browser engine flaws, that distinction is important because exploitation often depends on a prior foothold, a malicious file, or an attacker-controlled rendering path rather than a direct network probe.
The key practitioner question is therefore not whether the bug exists, but whether the environment exposes the vulnerable component in a way an attacker can reach. With browser and rendering-engine issues, that usually means confirming which products embed the affected code path and whether users can be driven to process attacker-supplied content.
For broader vulnerability context, the NIST National Vulnerability Database and the CVE Program are the right references for record-level identity and metadata, while CISA’s catalog is the operational indicator that exploitation has moved beyond disclosure.
Why a renderer-process weakness changes the exposure profile
Google Skia sits in a graphics-heavy part of the browser stack, so an integer overflow there is not just a generic memory-safety bug. The realistic danger is that attacker-controlled content reaches the rendering pipeline, the flaw is triggered inside a constrained process, and the exploit then attempts to cross the sandbox boundary into higher-value browser state or local code execution.
That makes the risk model different from a simple crash bug. The important failure condition is not only “can the code be hit,” but “can the attacker convert rendering control into a sandbox escape or a second-stage exploit.” That is why browser-engine issues tend to be chained with another weakness, malicious file content, or a separate privilege boundary bypass.
Where browser hardening matters, an enterprise browser control plane can reduce the blast radius. The Enterprise Browser and Browser Security Guide is useful here because it focuses attention on browser isolation, extension control, policy enforcement, and credential protection, all of which affect how much damage a successful renderer exploit can do.
What to do when patching cannot happen immediately
If you cannot patch at once, treat the problem as an active exploitation exposure, not a future maintenance task. The immediate objective is to shrink the attack surface that lets untrusted content reach the vulnerable code path, then to raise detection around unusual browser behavior, crash patterns, and suspicious file-handling activity.
Failure mechanism: An attacker first gets the renderer to process crafted content, then uses the integer overflow to influence memory handling and attempt a sandbox escape or adjacent compromise. If the user or endpoint can open attacker-supplied files, previews, or web content without isolation, the exploit path becomes materially easier.
Impact: Successful exploitation can lead to browser compromise, session theft, local foothold expansion, or a stepping stone into broader endpoint access. Even when the end state is limited by sandboxing, active exploitation means you should assume the flaw is being operationalised somewhere in the wild.
Zero-Day and Exploited Vulnerabilities Guide
For prioritisation, the Zero-Day and Exploited Vulnerabilities Guide is the best internal companion because it explains why KEV status changes urgency, how to think about emergency mitigation, and what post-fix validation should look like when exploitation is already underway.
The broader vulnerability programme view in the Vulnerability Management Guide also applies, since this question is really about triage, exposure confirmation, exception handling, and verifying that remediation actually removed the practical attack path.
For prioritisation signals, CISA’s Known Exploited Vulnerabilities Catalog is the authoritative operational reference, and EPSS can be a useful secondary input when you need to decide what to move first across a backlog.
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 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 | Active exploitation and KEV status make vulnerability prioritisation central. |
| Recommendation — Prioritise and remediate KEV-listed flaws first, then verify exposed assets are actually fixed. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | This is a live vulnerability exposure requiring confirmation and remediation tracking. |
| Recommendation — Track exposure, validate affected assets, and accelerate remediation for the exploited weakness. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The flaw is a memory-safety weakness in rendering code, so secure architecture and coding discipline matter. |
| V16 — Security Logging and Error Handling | Post-exploitation validation depends on observing crashes, errors, and suspicious renderer behavior. | |
| Recommendation — Review rendering and content-handling code paths for memory-safety weaknesses and exploit chaining. Retain and review crash and error telemetry that can confirm exploit attempts or follow-on abuse. | ||
| MITRE ATT&CK | T1203 — Exploitation for Client Execution | The issue concerns exploitation through crafted content reaching a client-side rendering path. |
| Recommendation — Map suspicious rendering-triggered execution to client-side exploitation and hunt for related behavior. | ||
Practitioner Guidance
What to verify: Confirm which browsers, embedded web views, and downstream applications use the affected rendering stack, then validate whether users can reach it through normal browsing, file preview, document rendering, or in-app web content. Do not assume one patched browser family covers every component that embeds the same engine.
Decision rule: If the vulnerable component is internet-reachable or exposed to untrusted content, prioritise emergency remediation and temporary exposure reduction before deeper forensic work. If patching must wait, isolate high-risk browsing paths, restrict file ingestion, and increase endpoint monitoring for renderer crashes or exploit-like behavior.
What good looks like: The organisation can name every exposed product instance, show that the vulnerable code path is either remediated or constrained, and produce evidence that suspicious crashes, repeated rendering faults, or related exploitation attempts are being reviewed promptly.
Practitioner takeaway: For a KEV-listed browser-engine flaw, the main decision is not whether exploitation is possible in theory, but whether you have reduced the reachable attack surface quickly enough to stay ahead of active abuse.