Google Chrome CVE-2026-102318

Exploitation requires the victim to actively load attacker-controlled HTML that exercises the WebGL rendering path in a Chrome build prior to 154.0.8037.92 - this user interaction (UI:R, visiting a malicious or compromised page) is the primary limiting factor. No authentication or special privileges are needed (PR:N), and no non-default configuration is required since WebGL is enabled by default in Chrome. The realistic impact is capped at a limited memory read (C:L only), so the condition that meaningfully constrains value to an attacker is the small and largely uncontrollable quantity of data disclosed rather than any access barrier.

This is a genuinely low-priority issue despite the eye-catching 'read memory outside the sandbox' language. The NVD CVSS 3.1 score is only 4.7 (Medium) with vector AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N - network-reachable and low-complexity, but the sole impact is a LOW confidentiality leak (C:L, I:N, A:N), meaning it discloses a bounded amount of adjacent memory rather than enabling code execution or a full sandbox escape. Note the divergence between Chromium's internal 'High' security-severity rating and the NVD-style base score of 4.7: Chromium's rating weights the WebGL/GPU-process attack surface and cross-boundary read (reflected in the S:C scope change) more heavily than the modest disclosed data. No EPSS score, no CISA KEV listing, and no public POC are present in the provided data, so exploitation status is 'no public exploit identified at time of analysis.' There is no SSVC decision data in the input. Bottom line: this is a high-CVSS-narrative but low-real-risk information-disclosure bug - patch it via the normal Chrome auto-update cycle, but it does not warrant emergency response. The 'outside the sandbox' phrasing combined with only C:L (no I/A) is worth verifying with the vendor, as it implies a cross-process read of limited scope rather than a controllable leak.

An attacker hosts or compromises a web page containing crafted WebGL content and lures a victim to visit it in a vulnerable Chrome build (before 154.0.8037.92). When the victim's browser renders the page, the out-of-bounds read in WebGL leaks a small amount of memory from outside the renderer sandbox back to attacker-controlled script. No public exploit code is identified at time of analysis, and success requires the user to load the malicious page (UI:R).