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

CVE-2026-17986 has a contested CVSS base score of 6.5 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-17986?

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

Google Chrome CVE-2026-17986

EUVD-2026-50912 MEDIUM

Improper Access Control (CWE-284)

2026-07-30 Chrome

GHSA-p6v2-jmfg-m6r4

Authentication Bypass Google

Medium

Disputed · 6.5 Vendor: Chrome

Severity by source

Sources disagree (Low–Critical)

Vendor (Chrome) PRIMARY

6.5 MEDIUM

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

vuln.today AI

5.3 MEDIUM

Renderer process compromise is an explicit prerequisite, raising AC to H; no authentication is needed from the attacker, and integrity-only impact reflects SOP bypass without confidentiality loss.

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

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

SUSE

CRITICAL

qualitative

Red Hat

8.7 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

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

None

Integrity

High

Availability

None

Lifecycle Timeline

Analysis Generated

Jul 30, 2026 - 19:31 vuln.today

CVSS changed

Jul 30, 2026 - 19:22 NVD

6.5 (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 6.5

DescriptionCVE.org

Insufficient policy enforcement in Bluetooth in Google Chrome prior to 151.0.7922.72 allowed a remote attacker who had compromised the renderer process to bypass same origin policy via a crafted HTML page. (Chromium security severity: Low)

AnalysisAI

Same-origin policy bypass in Google Chrome's Bluetooth subsystem (prior to 151.0.7922.72) can be triggered by an attacker who has already achieved renderer process compromise, using a crafted HTML page to abuse insufficient policy enforcement in the Web Bluetooth layer. The exploit chain requires a pre-existing foothold in the renderer, which limits real-world risk considerably - Chrome's own security team rated this 'Low' severity. No active exploitation has been confirmed (not listed in CISA KEV), and the EPSS score of 0.18% (8th percentile) reflects negligible observed exploitation activity.

Technical ContextAI

The affected component is Google Chrome's Bluetooth policy enforcement layer, most likely the Web Bluetooth API implementation that allows web pages to interact with nearby Bluetooth devices. CWE-284 (Improper Access Control) identifies the root cause: the browser fails to correctly enforce access policy boundaries in the Bluetooth subsystem when the renderer is under attacker control. Normally, Chrome's multi-process sandbox architecture uses the browser process as a policy authority over renderer requests, but this flaw allows an already-compromised renderer to abuse Bluetooth-related interfaces to cross same-origin boundaries. The CPE cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:* covers all Chrome variants on all platforms prior to the fixed release.

RemediationAI

Update Google Chrome to version 151.0.7922.72 or later via Chrome's built-in updater or by visiting chrome://settings/help. The vendor advisory is available at http://chromereleases.googleblog.com/2026/07/stable-channel-update-for-desktop_0887107924.html. Because exploitation requires a compromised renderer process as a prerequisite, organizations that already enforce Chrome enterprise policies - such as disabling the Web Bluetooth API via the DefaultWebBluetoothGuardSetting policy (set to 2 to block all sites) - will limit the Bluetooth attack surface independently of patching. Disabling Web Bluetooth has minimal operational impact in most enterprise environments that do not rely on browser-based Bluetooth device interactions. Patching remains the definitive fix; the policy workaround is a compensating control only.