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

CVE-2026-8526 has a CVSS 3.1 base score of 8.8 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.1%.

Which versions of Google Chrome are affected by CVE-2026-8526?

Google Chrome users face a high-severity vulnerability (CVE-2026-8526) allowing attackers to compromise computers through malicious websites; while no active exploitation has been detected and…. A patch is available.

How to fix or mitigate CVE-2026-8526?

Within 24 hours: Announce patch availability (Chrome 148.0.7778.168) to all users via security alert and verify your patch management systems (Intune, Jamf, MDM) are configured to deploy automatically. Within 7 days: Confirm organizational deployment to patched version 148.0.7778.168 or later across 90% or more of Chrome installations via inventory tooling and apply forced updates via group policy or MDM if necessary. Within 30 days: Achieve 100% compliance across all Chrome deployments and conduct user awareness communication emphasizing the risks of visiting untrusted websites while confirming Safe Browsing is enabled.

Google Chrome CVE-2026-8526

EUVD-2026-30440 HIGH

Out-of-bounds Write (CWE-787)

2026-05-14 Chrome

GHSA-vrq8-3x54-8jj3

RCE Buffer Overflow Google Memory Corruption

8.8

CVSS 3.1 · NVD

Severity by source

NVD 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

Remote crafted page needs no auth but requires the victim to open it (UI:R); sandboxed RCE keeps scope unchanged (S:U) yet yields high C/I/A within the renderer.

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:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

SUSE

HIGH

qualitative

Red Hat

9.6 HIGH

qualitative

Primary rating from NVD.

CVSS VectorNVD

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 23, 2026 - 18:44 vuln.today

CVSS changed

May 14, 2026 - 22:22 NVD

8.8 (HIGH)

CVE Published

May 14, 2026 - 19:52 nvd

UNKNOWN (no severity yet)

CVE Published

May 14, 2026 - 19:52 nvd

HIGH 8.8

DescriptionCVE.org

Out of bounds write in WebRTC in Google Chrome prior to 148.0.7778.168 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)

AnalysisAI

Out-of-bounds write in the WebRTC component of Google Chrome before 148.0.7778.168 lets a remote attacker achieve arbitrary code execution inside the renderer sandbox when a victim opens a crafted HTML page. Rated High by Chromium and CVSS 8.8, it requires user interaction (visiting a page) but no authentication. There is no public exploit identified at time of analysis, EPSS is low (0.07%), and CISA SSVC lists exploitation as none, indicating no observed in-the-wild activity yet.

Technical ContextAI

The flaw is a CWE-787 out-of-bounds write in WebRTC, the real-time communication engine built into Chromium that handles audio/video peer connections, RTP/SRTP media, data channels, and codec processing directly from web content. Memory-safety defects in this stack are historically valuable because WebRTC parses attacker-influenced media and session data in the renderer process. The single affected CPE is cpe:2.3:a:google:chrome and, by shared-code inheritance, other Chromium-based browsers and the Red Hat/SUSE Chromium packages referenced in the tags. An out-of-bounds write corrupts memory adjacent to an intended buffer, which can be leveraged to control execution flow.

RemediationAI

Vendor-released patch: update Google Chrome to 148.0.7778.168 or later via the Stable channel (chrome://settings/help forces the check and applies the update on restart), per https://chromereleases.googleblog.com/2026/05/stable-channel-update-for-desktop_12.html; Chromium-based and distribution packages (Red Hat, SUSE) should be upgraded to the vendor's fixed rebuild once published. As an interim compensating control before patching, reducing WebRTC exposure lowers the attack surface - enterprise administrators can restrict it via policy (URLBlocklist, WebRtcUdpPortRange limits, or disabling WebRTC media flags) - with the trade-off that video conferencing, screen sharing, and voice features (Meet, Teams web, and similar) will break. Restricting browsing to trusted sites and enforcing prompt auto-update are lower-friction stopgaps until the update is deployed.