CVE-2023-6345 is an integer overflow vulnerability in Google Chromium Skia. CISA added it to the Known Exploited Vulnerabilities catalogue on 30 November 2023, which means attackers have used it in real attacks. This vulnerability affects Google Chrome and ChromeOS, Android, Flutter, and possibly other products.
What makes an integer overflow in a rendering engine dangerous?
An integer overflow in a graphics component can corrupt size calculations, memory bounds, or allocation logic before data is rendered. In browser and app rendering paths, that can turn seemingly ordinary content into a crash, corruption, or code execution opportunity.
Skia is a shared rendering library, so a flaw in its arithmetic can matter well beyond one product. The same code path may be reached through web content, embedded views, or applications that rely on the rendering stack, which is why exposure assessment starts with understanding where the library is used and how it is reached.
Where this vulnerability tends to appear
Integer overflow issues in rendering engines are usually rooted in untrusted input that influences dimensions, counts, offsets, or buffer lengths. If those values wrap around, later checks may operate on the wrong number, creating a mismatch between the intended object size and the memory actually used.
The practical danger is not the arithmetic bug by itself, but what the bug enables next. In a graphics pipeline, malformed content can cross trust boundaries from parser to renderer to memory manager, and that is why browser-style vulnerabilities are often treated as high priority even when the trigger seems like “just” image or page processing.
For authoritative record details, use the CVE Program for the vulnerability identifier and the NIST National Vulnerability Database for the canonical record and related metadata.
How organisations check exposure and prioritise response
Exposure review should begin with asset inventory, because this issue affects multiple products that embed the same rendering code. The key question is not only whether Chrome is installed, but which browsers, SDKs, mobile builds, and downstream applications include the affected component.
Internet exposure matters as well. Systems that render attacker-controlled content from the web, documents, ads, chat payloads, or remote feeds are higher risk than isolated internal tooling, especially when the vulnerable path is reachable before strong sandboxing or isolation takes effect.
Prioritisation should also follow vendor advisories and exploitability signals rather than waiting for convenience. When a CVE is in the Known Exploited Vulnerabilities catalogue, the assumption should be that the issue is already operationally relevant and should be treated as active exposure, not theoretical weakness.
Remediation, detection, and post-exploitation review
The preferred fix is the vendor patch or updated build that removes the faulty arithmetic path. When immediate patching is not possible, reduce exposure by limiting untrusted rendering, constraining affected apps to safer network and content paths, and removing unnecessary access to the vulnerable surface.
Detection should focus on crashes, unusual renderer termination, sandbox escapes, and other signs that content parsing or rendering behaved unexpectedly. After patching, review whether the system showed prior compromise indicators, because exploitation of a memory-safety bug can leave behind secondary payloads even if the rendering flaw itself is closed.
If the vulnerable component handled authenticated sessions, downloaded content, or enterprise app data, treat the incident as more than a stability issue. Review affected endpoints for browser persistence, malicious extensions, credential reuse, and follow-on access that could have been established during exploitation.
Risk and Threat Considerations
This type of flaw is dangerous because it sits in a high-trust code path that processes content from outside the organisation. Attackers value rendering bugs when they can turn a simple parse or display action into memory corruption, crash chaining, or remote code execution in a broadly deployed product.
Failure mechanism: Arithmetic wraparound changes the true size or offset of an object, so later memory operations act on a corrupted boundary and may read, write, or allocate incorrectly.
Impact: The outcome can range from denial of service to code execution, depending on the exact control flow and memory-safety conditions in the target build.
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 NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | This CVE requires finding and prioritizing vulnerable software across the fleet. |
| Recommendation — Prioritise and remediate exposed Skia-containing products through continuous vulnerability management. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | This CVE depends on identifying affected assets and tracking exposure. |
| SI-2 — Flaw Remediation | This is a software flaw that requires patching or compensating remediation. | |
| Recommendation — Scan for affected products and validate exposure against vendor advisories. Apply the vendor fix and track remediation until the vulnerable build is removed. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and documented | Exposure assessment for this CVE begins with knowing where the vulnerable component exists. |
| Recommendation — Inventory products that embed the vulnerable rendering library and document exposure. | ||
| MITRE ATT&CK | T1203 — Exploitation for Client Execution | Browser and rendering flaws commonly support client-side exploitation leading to code execution. |
| Recommendation — Monitor for malicious content delivery that attempts client-side exploitation. | ||
Practitioner Guidance
Why practitioners should care: Rendering vulnerabilities often have wide blast radius because the same library is embedded across browsers, mobile platforms, and application frameworks. Treat the affected component as shared infrastructure, not as a single-product issue.
What to watch for: Prioritise systems that process untrusted remote content, especially public-facing browsers, embedded web views, and application stacks that inherit the renderer indirectly. Those are the paths most likely to be reachable by an attacker without insider access.
Practitioner takeaway: Build your response around asset discovery, vendor remediation, and compromise review, then verify that the vulnerable render path is no longer reachable in your environment.