Severity by source
AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
Network-delivered via crafted page (AV:N), requires victim navigation (UI:R), no privileges needed (PR:N), impact limited to UI spoofing with no availability effect (C:L/I:L/A:N).
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
4DescriptionNVD
Inappropriate implementation in WebXR in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low)
AnalysisAI
UI spoofing in Google Chrome's WebXR component (all versions prior to 150.0.7871.47) allows remote attackers to misrepresent browser interface elements when a victim visits a crafted HTML page. The flaw stems from an inappropriate implementation in the WebXR Device API, enabling manipulation of what the user perceives as trusted UI - potentially obscuring origin indicators, security state, or page identity. No public exploit code exists and EPSS stands at 0.18% (8th percentile); CISA SSVC rates exploitation as none with partial technical impact, placing this firmly in the lower-priority tier despite its network-accessible vector.
Technical ContextAI
The WebXR Device API (cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:*) enables immersive virtual and augmented reality experiences directly within the browser context. CWE-451 (User Interface Misrepresentation of Critical Information) identifies the root cause: Chrome's WebXR implementation fails to correctly enforce the boundary between application-controlled and browser-controlled UI, allowing a crafted HTML page to influence elements the user would otherwise trust as browser-owned - such as origin indicators, permission prompts, or security chrome. This class of vulnerability is particularly dangerous in immersive contexts where the browser's trusted UI surface is already reduced or obscured by the XR environment. The Chromium tracking issue (514039492) contains additional technical detail that may be access-restricted.
RemediationAI
Upgrade Google Chrome to version 150.0.7871.47 or later via the Chrome stable channel update documented at https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html; this is the vendor-confirmed fix and the primary remediation. For enterprise environments unable to patch immediately, WebXR can be disabled via Chrome enterprise policy (WebXrEnabled=false via GPO or chrome://flags/#webxr-incubations), which eliminates the attack surface entirely but also disables all WebXR functionality for end users - a trade-off appropriate only for environments where XR content is not operationally required. Blocking navigation to untrusted external HTML pages via proxy or content filtering provides additional depth but is not a substitute for patching given the low complexity of hosting a malicious page.
Same technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: Moderate| Product | Status |
|---|---|
| SUSE Package Hub 15 SP7 | Fixed |
| openSUSE Tumbleweed | Fixed |
| SUSE Package Hub 15 SP7 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-40819
GHSA-rjp5-8cgw-rxgg