What is the CVSS score of CVE-2026-17906?

CVE-2026-17906 has a contested CVSS base score of 5.8 from a third party (e.g. CISA-ADP), while the vendor rates it Medium. vuln.today uses the vendor rating as authoritative.

Is there a patch available for CVE-2026-17906?

Yes, a patch is available for CVE-2026-17906. Update the affected software to the latest version immediately.

Google Chrome CVE-2026-17906

EUVD-2026-50655 MEDIUM

Improper Input Validation (CWE-20)

2026-07-30 Chrome

GHSA-grfx-v4xp-4m33

Information Disclosure Google

Medium

Disputed · 5.8 Vendor: Chrome

Severity by source

Sources disagree (Low–Critical)

Vendor (Chrome) PRIMARY

5.8 MEDIUM

AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:L

vuln.today AI

5.8 MEDIUM

Chained attack requiring prior renderer compromise justifies AC:H; sandbox escape changes scope to S:C; no system authentication required but renderer must already be controlled.

3.1 AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:L

4.0 AV:N/AC:L/AT:P/PR:N/UI:A/VC:L/VI:L/VA:L/SC:L/SI:L/SA:N

SUSE

CRITICAL

qualitative

Red Hat

0.0 LOW

qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Chrome

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

Required

Scope

Changed

Confidentiality

Low

Integrity

Low

Availability

Low

Lifecycle Timeline

Analysis Generated

Jul 30, 2026 - 19:30 vuln.today

CVSS changed

Jul 30, 2026 - 19:22 NVD

5.8 (MEDIUM)

Patch available

Jul 30, 2026 - 02:02 EUVD

CVE Published

Jul 30, 2026 - 00:25 cve.org

UNKNOWN (no severity yet)

CVE Published

Jul 30, 2026 - 00:25 cve.org

MEDIUM 5.8

DescriptionCVE.org

Insufficient validation of untrusted input in Bluetooth in Google Chrome prior to 151.0.7922.72 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Low)

AnalysisAI

Sandbox escape in Google Chrome's Bluetooth component (all versions prior to 151.0.7922.72) allows an attacker who has already compromised the renderer process to break out of Chrome's sandbox by sending crafted Bluetooth IPC messages triggered via a malicious HTML page. This is a second-stage, chained exploit - not a standalone remote attack - requiring prior renderer compromise as a hard prerequisite, which is why Chromium rates it Low severity internally despite the sandbox escape classification. No public exploit code or CISA KEV listing has been identified; EPSS of 0.17% at the 7th percentile reflects low exploitation probability consistent with the high attack chain complexity.

Technical ContextAI

Chrome's multi-process architecture isolates web content in sandboxed renderer processes, communicating with the privileged browser process via strictly validated IPC channels. The vulnerability (CWE-20: Improper Input Validation) exists in Chrome's Bluetooth subsystem, where IPC messages originating from the renderer are processed without sufficient validation of untrusted input. A compromised renderer can craft malformed Bluetooth-related messages that bypass this validation, causing the browser process - which runs with higher OS privileges - to execute attacker-controlled logic, thereby crossing the sandbox boundary. The scope change (S:C) in the provided CVSS vector formally reflects this privilege boundary crossing. The affected CPE (cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:*) covers all Chrome desktop versions prior to 151.0.7922.72 without platform restriction. The Bluetooth component's presence in the IPC attack surface is notable - hardware-adjacent subsystems often receive less hardening scrutiny than core web platform components.

RemediationAI

Update Google Chrome to version 151.0.7922.72 or later immediately; this is the vendor-released patch per the Chrome Releases advisory at https://chromereleases.googleblog.com/2026/07/stable-channel-update-for-desktop_0887107924.html. The update is available via Chrome's built-in mechanism (Settings > Help > About Google Chrome triggers an update check) or via enterprise deployment through Google Admin Console or endpoint management platforms (Intune, SCCM, etc.). If patching is temporarily blocked by change control, the most targeted compensating control is to restrict or block access to untrusted external web content via proxy or DNS filtering, since exploitation begins with a user visiting a crafted HTML page - this reduces but does not eliminate exposure. Disabling Bluetooth at the OS level would theoretically sever the specific Bluetooth IPC path, but the operational trade-off of disabling Bluetooth enterprise-wide is almost never acceptable. Note that any compensating control is secondary to patching: the chaining prerequisite (renderer compromise) is itself addressed by keeping Chrome current, since renderer RCEs are also patched in Chrome releases.