Google Chrome CVE-2026-11657

Exploitation requires the victim to be running Google Chrome on macOS at a version below 149.0.7827.103 and to navigate to (or have rendered) attacker-controlled HTML/JavaScript that triggers the Payments component - per CVSS UI:R, user interaction in the form of visiting the malicious page is required. No authentication or pre-existing privileges on the target system are needed (PR:N), and attack complexity is low (AC:L), meaning no race window or unusual environment must be won. Limiting factors: the bug appears scoped to the macOS build per the description (Windows/Linux not named), the issue resides in the Payments code path which may require the attacker page to invoke specific Payment Request API constructs to reach the vulnerable allocation, and successful renderer code execution remains confined to the Chrome sandbox (S:U) unless chained with a separate sandbox escape.

The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H reflects a realistic browser-RCE profile: network reachable, low complexity, no authentication, but requires user interaction (visiting a malicious page) and does not cross the renderer sandbox (S:U). Google rates the underlying Chromium severity as High, and the tags note RCE, DoS, and memory corruption potential. No EPSS score, KEV listing, or public POC was provided in the source data, and the bug is not flagged as actively exploited - this contrasts with Chrome zero-days that Google typically calls out explicitly in release notes, so the absence of such language is itself a (soft) signal that in-the-wild exploitation is not currently known. Real-world priority is high for any organization with significant macOS Chrome usage because use-after-free bugs in renderer-exposed components are historically chained with sandbox escapes by sophisticated actors, but the lack of confirmed exploitation and the UI:R requirement put it below drop-everything urgency.

An attacker hosts a malicious web page (or compromises an ad network / serves a malicious iframe) that exercises the Chrome Payments code path with crafted JavaScript designed to trigger the use-after-free; a macOS Chrome user on a vulnerable build visits the page and the renderer is hijacked, giving the attacker code execution inside the sandboxed renderer process. To achieve full system compromise the attacker would typically chain a separate macOS renderer sandbox escape; absent that, the renderer-level access still enables credential theft, session hijacking, and cross-site data exfiltration from the victim's browsing session. No public POC is identified at time of analysis.