CVE-2026-113221 in Chromeinfo

Summary

by MITRE • 10/21/2026

Use after free in Google Lens in Google Chrome prior to 156.0.8078.47 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium)

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 10/21/2026

The vulnerability identified as a use-after-free flaw within Google Lens, specifically affecting versions of Google Chrome prior to 156.0.8078.47, represents a critical memory management error that compromises the integrity of the browser's sandboxing mechanisms. This type of defect occurs when a program continues to use a pointer after the memory it points to has been freed and potentially reallocated for other purposes. In the context of Google Lens integration within Chrome, this flaw allows an attacker who crafts a malicious HTML page to trigger the premature deallocation of critical data structures while references to that same memory region remain active in the application's execution flow. When the browser subsequently attempts to access or manipulate these dangling pointers, it interacts with uninitialized or reused memory contents rather than the intended objects. This discrepancy creates an opportunity for arbitrary code execution because the attacker can control the content written into the freed memory block through carefully crafted input vectors embedded within the malicious webpage.

From a technical perspective, this vulnerability aligns closely with CWE-416, which classifies use-after-free errors as a distinct category of software weaknesses leading to undefined behavior and potential security breaches. The exploitation chain typically involves triggering specific rendering or processing routines in Google Lens that handle user input or image data without properly validating pointer lifecycles. By manipulating the timing and sequence of memory allocation and deallocation, an attacker can achieve heap spraying techniques where they fill the freed memory space with controlled shellcode or ROP gadgets. When the vulnerable code dereferences the stale pointer, it inadvertently executes this injected payload. Although Chrome employs robust sandboxing architectures designed to isolate renderer processes from the host operating system, a successful use-after-free exploit within these isolated environments can still lead to arbitrary code execution inside the sandbox boundary. This effectively bypasses several layers of defense-in-depth measures that rely on process isolation and restricted permissions.

The operational impact of this vulnerability is severe due to its remote exploitable nature via standard web technologies like HTML, CSS, and JavaScript. A user visiting a maliciously crafted website could unknowingly trigger the exploit without any additional interaction beyond loading the page or interacting with specific elements designed to activate the Google Lens component. Once arbitrary code execution is achieved within the sandboxed renderer process, an attacker gains significant foothold capabilities. While full system compromise may require further exploitation steps such as sandbox escapes, the initial breach allows for data exfiltration from the current browsing session, installation of persistent malware if combined with other vulnerabilities, or lateral movement in enterprise environments where Chrome is widely deployed. The medium severity rating assigned by Chromium reflects the complexity required to reliably exploit this flaw and the mitigating factors present in modern browser defenses, yet it remains a high-risk issue due to its potential for remote code execution.

To mitigate this risk, organizations must ensure that all instances of Google Chrome are updated to version 156.0.8078.47 or later immediately upon availability. This update contains the necessary patches that enforce proper memory management protocols within the Google Lens module, ensuring that pointers are nullified after deallocation and preventing access to freed memory regions. Additionally, security teams should implement strict content security policies and restrict the execution of untrusted scripts where possible to reduce the attack surface available to potential exploit attempts. Monitoring for anomalous network traffic or unusual process behavior originating from Chrome renderer processes can also aid in detecting attempted exploitation activities. Regular patch management cycles are essential to address such vulnerabilities promptly, as attackers frequently develop automated tools targeting known flaws before official updates are widely deployed across enterprise and consumer environments.

Responsible

Chrome

Reservation

10/20/2026

Disclosure

10/21/2026

Moderation

accepted

EPSS

0.00327

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!