Severity by source
AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
Renderer compromise prerequisite elevates AC to H; PR:N and UI:R match the direct WebXR exploitation step; I:L for UI spoofing only with no C or A impact.
Primary rating from Vendor (google).
CVSS VectorVendor: google
Lifecycle Timeline
4DescriptionCVE.org
Insufficient validation of untrusted input in WebXR in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)
AnalysisAI
UI spoofing in Google Chrome's WebXR subsystem (versions prior to 150.0.7871.47) is achievable by an attacker who has already compromised the renderer process, allowing manipulation of browser UI elements via a crafted HTML page. The vulnerability is a second-stage attack component, not a standalone entry point - exploitation chains through a separate renderer compromise before WebXR's insufficient input validation can be abused. EPSS at 0.17% (7th percentile) and no CISA KEV listing indicate minimal observed exploitation activity; patch is available as of Chrome 150.0.7871.47.
Technical ContextAI
WebXR is the browser API standardizing access to augmented and virtual reality hardware from web content. In Chrome's multi-process architecture, the renderer process handles JavaScript execution and DOM parsing in a sandboxed context, communicating with the privileged browser process via IPC. CWE-20 (Improper Input Validation) identifies the root cause: the WebXR handler in the browser process fails to adequately validate data received from the renderer over IPC. A compromised renderer can send maliciously crafted WebXR messages that the browser process accepts without sufficient scrutiny, allowing renderer-side content to influence browser-level UI rendering - a channel that should be strictly gated. No CPE strings were provided, but EUVD confirms affected versions as all Chrome desktop releases below 150.0.7871.47.
RemediationAI
Upgrade Google Chrome to version 150.0.7871.47 or later, as released in the stable channel update documented at chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html. Chrome's built-in auto-update mechanism will apply this patch automatically in most enterprise and consumer deployments; verify via chrome://settings/help. As a compensating control prior to patching, organizations may enforce Chrome's existing Site Isolation policy (enabled by default since Chrome 67) and ensure sandboxing is not administratively disabled, as renderer compromise - the necessary precondition - becomes harder to achieve with full sandbox enforcement. Disabling WebXR via enterprise policy (WebXrEnabled=false) would eliminate the attack surface at the cost of breaking XR web experiences, which may be acceptable in high-security environments where WebXR is not a business requirement.
Same weakness CWE-20 – Improper Input Validation
View allSame 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-40708
GHSA-9xm7-7v5p-655w