Google Chrome CVE-2026-102310

Exploitation requires that the attacker has ALREADY compromised the Chrome renderer process - this is the explicit precondition stated in the advisory and is the primary factor limiting real-world risk, since it presupposes a prior successful exploit against the browser. Given a compromised renderer, the attacker then delivers a crafted HTML page that triggers the missing authorization check in the Payments component to bypass web origin policy. Affected builds are Google Chrome desktop prior to 154.0.8037.92; user interaction (UI:R, loading/visiting the crafted page) is also required. No confidentiality or availability impact applies - only integrity (cross-origin action manipulation). The bug is not automatable per CISA SSVC and has no observed exploitation.

This is a genuinely low-priority issue despite the 6.5 CVSS base score, and the signals are consistent rather than conflicting. The CVSS vector (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N) scores it as network-reachable with high integrity impact, but the description imposes a severe gating precondition the base vector understates: the attacker must have ALREADY compromised the Chrome renderer process before this bug does anything. That makes it a secondary/sandbox-relevant weakness - a step in a longer chain, not a standalone entry point - which is exactly why Chromium itself rated the security severity 'Low'. CISA's SSVC framework corroborates low urgency: Exploitation=none (no observed activity), Automatable=no, Technical Impact=partial. No EPSS score was supplied, there is no CISA KEV listing, and no public exploit code was identified, so this is 'no public exploit identified at time of analysis.' The one nuance worth flagging: the vendor vector's PR:N/AC:L arguably overstates reachability because a compromised renderer is a substantial prerequisite - I assess higher complexity below. Bottom line: real but low-priority, addressed by simply staying current on Chrome auto-updates.

An attacker first achieves code execution in Chrome's renderer process (e.g. via a separate rendering-engine exploit) and then serves a crafted HTML page that abuses the Payments component's missing authorization check to act across a web origin it should not be able to reach, bypassing same-origin/web-origin policy. The integrity impact (I:H) reflects the ability to forge or manipulate payment-related actions in another origin's context. No public proof-of-concept or active exploitation is known.