Google Chrome EUVD-2026-50894

Exploitation requires that a victim actively navigate to an attacker-controlled HTML page using Google Chrome on Android - user interaction (UI:R) is a hard prerequisite that prevents fully automated mass exploitation. The crafted page must invoke the WebXR API, which is available by default in Chrome for Android but requires the attacker's page to be loaded and processed by the browser. The vulnerability is explicitly platform-specific: only Chrome running on Android is identified as affected; desktop Chrome on other operating systems is outside scope per the CVE description. No authentication is required from the attacker's perspective (PR:N per CVSS). The primary limiting factors are the mandatory user-interaction requirement, Android-platform specificity, and Chrome's sandboxed process model, which constrains what memory contents are accessible to the disclosure and limits lateral impact from any leaked data.

The CVSS 3.1 base score of 6.5 (Medium) reflects network reachability (AV:N), low complexity (AC:L), no required privileges (PR:N), mandatory user interaction (UI:R), and high confidentiality impact (C:H) with no integrity or availability impact. The EPSS score of 0.19% at the 9th percentile signals very low near-term exploitation probability, consistent with the SSVC assessment of exploitation: none, automatable: no, and technical impact: partial. The non-automatable designation directly aligns with the UI:R constraint - mass exploitation requires individually tricking users rather than autonomous scanning. No CISA KEV listing and no identified public exploit code further reduce urgency. The C:H rating may overstate practical impact: uninitialized memory disclosures in sandboxed browser processes may only leak low-value data, though in specific timing scenarios sensitive in-memory material such as session tokens or cached credentials could theoretically be exposed. Real-world risk is materially lower than the base CVSS implies; this warrants routine update-cycle remediation rather than emergency response.

An attacker hosts a crafted HTML page that invokes the WebXR API in a manner that triggers access to an uninitialized memory region, then lures an Android Chrome user to visit the page via phishing, malicious advertisement, or a compromised website. The browser processes the page, the WebXR subsystem reads uninitialized memory, and portions of browser process memory - potentially including data resident from prior operations - are returned to the attacker's JavaScript context. No public proof-of-concept exploit has been identified at time of analysis.