Google Chrome CVE-2026-113199

Exploitation requires the victim to use an affected Google Chrome build (any version prior to 156.0.8078.47) and to load an attacker-crafted HTML page that exercises the Payments component - this user interaction (UI:R) is the primary limiting factor, as the bug cannot be triggered without the target visiting attacker-controlled content. No authentication or special privileges are needed (PR:N). Impact is inherently constrained: the out-of-bounds read discloses memory only within the renderer sandbox (S:U, C:H/I:N/A:N), so it yields information disclosure rather than code execution or integrity/availability impact, and is most dangerous as a building block chained with a separate sandbox-escape vulnerability.

This is a genuinely moderate, not critical, priority. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N, base 6.5) describes a remote, low-complexity, unauthenticated (PR:N) attack that nonetheless requires user interaction (UI:R) - the victim must open a crafted HTML page - with impact limited to confidentiality (C:H, I:N, A:N). The impact is further bounded because the description explicitly states the attacker reads memory 'inside the sandbox' (S:U, no scope change), so this is an information leak confined to the renderer sandbox, not a sandbox escape or code execution. Supporting signals all point the same direction: EPSS is 0.19% (9th percentile), this is NOT on the CISA KEV list, and no POC is referenced - exploitation status is therefore 'no public exploit identified at time of analysis.' Google itself rated the Chromium severity Medium, consistent with the sandbox-contained read. No signals conflict here: low EPSS, no KEV, no POC, and a Medium vendor rating all align with a lower-urgency item. The main residual risk driver is prevalence - Chrome's enormous install base means even a Medium bug warrants prompt patching - but there is no evidence of active or imminent widespread exploitation.

An attacker hosts or injects a crafted HTML page that drives the Payments component into an out-of-bounds read when a victim browses to it. The leaked renderer-sandbox memory could expose sensitive in-process data (e.g., tokens, address-space layout useful to chain with another bug), but by itself it neither escapes the sandbox nor executes code. No public exploit code is known, and successful exploitation depends on the victim actually loading the attacker-controlled page.