What is the CVSS score of EUVD-2026-40564?

EUVD-2026-40564 has a contested CVSS base score of 9.6 from a third party (e.g. CISA-ADP), while the vendor rates it Critical. vuln.today uses the vendor rating as authoritative.

Which versions of Google Chrome are affected by EUVD-2026-40564?

Google Chrome on macOS (versions prior to 150.0.7871.47) contains a critical vulnerability allowing attackers to break browser security isolation.. A patch is available.

How to fix or mitigate EUVD-2026-40564?

Within 24 hours: prepare and deploy Chrome 150.0.7871.47 or later to all macOS systems using auto-update or managed channels; communicate urgency to end users and IT teams. Within 7 days: confirm 100% upgrade compliance across macOS endpoints via device inventory and telemetry systems; restrict any pre-150.0.7871.47 instances from network access if feasible. Within 30 days: review endpoint logs for abnormal Bluetooth activity or crash patterns consistent with exploit attempts; validate final compliance and archive evidence of patching.

Google Chrome EUVD-2026-40564

| CVE-2026-13878 CRITICAL

Use After Free (CWE-416)

2026-06-30 chrome-cve-admin@google.com

GHSA-j864-w7vw-6xg3

Denial Of Service Google Use After Free Memory Corruption Red Hat

Critical

Disputed · 9.6 Vendor: google

Severity by source

Sources disagree (Medium–Critical)

Vendor (google) PRIMARY

9.6 CRITICAL

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

vuln.today AI

7.6 HIGH

Requires a prior renderer compromise (PR:H) plus reliable UAF grooming and a victim page-load (AC:H, UI:R); a successful escape changes scope and fully compromises the browser process (S:C, C/I/A:H).

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

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

SUSE

CRITICAL

qualitative

Red Hat

8.7 MEDIUM

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: google

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 22, 2026 - 19:55 vuln.today

CVE Published

Jun 30, 2026 - 23:17 cve.org

CRITICAL 9.6

CVE Published

Jun 30, 2026 - 23:17 cve.org

UNKNOWN (no severity yet)

DescriptionCVE.org

Use after free in Bluetooth in Google Chrome on Mac prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium)

AnalysisAI

Sandbox escape in Google Chrome on macOS (versions prior to 150.0.7871.47) arises from a use-after-free in the browser's Bluetooth component, letting an attacker who has already compromised the renderer process break out of the sandbox and reach the higher-privileged browser process via a crafted HTML page. This is a second-stage exploitation primitive rather than an initial-access flaw, which is why Google rates the Chromium severity as Medium despite the 9.6 CVSS. No public exploit has been identified, there is no CISA KEV listing, and EPSS exploitation probability is low (0.21%, 11th percentile).

Technical ContextAI

The issue is a CWE-416 use-after-free in Chrome's Bluetooth stack (Web Bluetooth / device backend) as implemented on macOS. A use-after-free occurs when memory is freed but a dangling pointer to it is later dereferenced, allowing an attacker who controls heap allocation to reclaim the freed region and influence program flow. Because the vulnerable code path executes in the privileged browser process rather than the sandboxed renderer, corrupting it from a compromised renderer crosses the sandbox boundary - captured by the CVSS scope change (S:C). The single affected CPE is cpe:2.3:a:google:chrome, and the vendor scopes the defect specifically to the Mac platform.

RemediationAI

Vendor-released patch: update Google Chrome on macOS to 150.0.7871.47 or later via the Stable channel update described at https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html, then relaunch the browser so the new binary is loaded, since Chrome applies updates on restart. There is no supported configuration-only workaround because the flaw lives in the browser process; however, because the bug is in the Bluetooth backend, managed environments can reduce exposure by disabling Web Bluetooth through enterprise policy (set DefaultWebBluetoothGuardSetting to block access) - the trade-off is that any legitimate site or internal tool relying on Web Bluetooth will stop working. Since exploitation also requires a prior renderer compromise, keeping Chrome fully current to close renderer-side RCEs is the most effective compensating control.