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

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

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

A heap corruption vulnerability in Google Chrome (CVE-2026-14040) could permit code execution if users install a malicious browser extension.. A patch is available.

How to fix or mitigate EUVD-2026-40727?

Within 24 hours: Confirm Chrome auto-update status across enterprise deployments and distribute security alert prohibiting installation of unvetted extensions. Within 7 days: Deploy Chrome version 150.0.7871.47 or later across all desktop systems. Within 30 days: Audit and enforce extension policies via Group Policy or MDM to prevent installation of unsigned or external extensions.

Google Chrome EUVD-2026-40727

| CVE-2026-14040 HIGH

Use After Free (CWE-416)

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

GHSA-xm2c-mv2p-hffr

Denial Of Service Google Use After Free Memory Corruption Red Hat Suse

High

Disputed · 8.8 Vendor: google

Severity by source

Sources disagree (Low–High)

Vendor (google) PRIMARY

8.8 HIGH

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

vuln.today AI

8.8 HIGH

Attacker needs no account (PR:N) but the victim must actively install a malicious extension (UI:R); a successful heap-corruption use-after-free can yield high C/I/A within the browser process.

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

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

SUSE

HIGH

qualitative

Red Hat

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 01, 2026 - 14:28 vuln.today

CVSS changed

Jul 01, 2026 - 14:22 NVD

8.8 (HIGH)

CVE Published

Jun 30, 2026 - 23:17 cve.org

UNKNOWN (no severity yet)

CVE Published

Jun 30, 2026 - 23:17 cve.org

HIGH 8.8

DescriptionCVE.org

Use after free in BrowserTag in Google Chrome prior to 150.0.7871.47 allowed an attacker who convinced a user to install a malicious extension to potentially exploit heap corruption via a crafted Chrome Extension. (Chromium security severity: Low)

AnalysisAI

Heap corruption in Google Chrome's BrowserTag component affects all desktop builds prior to 150.0.7871.47, where a use-after-free (CWE-416) can be triggered by a crafted Chrome extension. An attacker who convinces a victim to install a malicious extension can potentially exploit the freed-memory condition to corrupt the heap and execute code. No public exploit identified at time of analysis, and EPSS is low (0.12%, 2nd percentile), consistent with the Chromium team's own 'Low' severity rating despite the NVD CVSS of 8.8.

Technical ContextAI

The flaw is a use-after-free (CWE-416) in BrowserTag, an internal Chromium browser-side object, reachable through the Chrome Extensions API surface. Use-after-free occurs when memory is freed but a dangling pointer is later dereferenced or reused, letting an attacker who controls heap allocation reclaim the slot with attacker-chosen data and pivot to heap corruption. CPE-level detail is limited: EUVD lists the affected boundary as 'Chrome <150.0.7871.47', which covers the Stable desktop channel (Windows, macOS, Linux) built on the Chromium engine. The Chromium tracker issue 497488593 is access-restricted (standard for unpatched Chrome bugs), so the exact object lifecycle bug is not publicly documented.

RemediationAI

Vendor-released patch: update Google Chrome to 150.0.7871.47 or later, per the Chrome Releases advisory (https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html); most installs receive this automatically, but force a restart to apply the update and verify via chrome://settings/help. Because exploitation requires a malicious extension, an effective compensating control before/after patching is to restrict extension installation: enable enterprise policy ExtensionInstallBlocklist='*' with an ExtensionInstallAllowlist of vetted IDs, or set ExtensionInstallForcelist to curate only approved extensions - the trade-off is that users lose the ability to self-install extensions and helpdesk load may rise. Downstream Chromium browsers should be updated to the build that incorporates the corresponding upstream fix. There is no need for a network-level workaround since the trigger is a locally installed extension, not remote content.