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

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

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

Google Chrome versions prior to 149.0.7827.53 contain a vulnerability enabling attackers to escape the browser sandbox and gain system-level access once the renderer process is compromised.. A patch is available.

How to fix or mitigate CVE-2026-10898?

Within 24 hours: Inventory all Chrome deployments and identify distribution method (manual, enterprise endpoint management, etc.). Within 7 days: Begin staged deployment of Chrome 149.0.7827.53 or later, prioritizing systems with administrative privileges or access to sensitive data. Within 30 days: Complete organization-wide deployment and confirm all Chrome instances are updated via inventory verification.

Google Chrome CVE-2026-10898

EUVD-2026-34347 HIGH

Stack-based Buffer Overflow (CWE-121)

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

GHSA-g42g-w9j9-78hj

Google Stack Overflow Buffer Overflow Red Hat Suse Chrome

8.3

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

8.3 HIGH

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

SUSE

HIGH

qualitative

Red Hat

8.2 HIGH

qualitative

Primary rating from NVD.

CVSS VectorNVD

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

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

Required

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jun 05, 2026 - 02:27 vuln.today

CVSS changed

Jun 05, 2026 - 02:22 NVD

8.3 (HIGH)

CVE Published

Jun 04, 2026 - 23:16 nvd

HIGH 8.3

CVE Published

Jun 04, 2026 - 23:16 nvd

UNKNOWN (no severity yet)

DescriptionCVE.org

Stack buffer overflow in GPU in Google Chrome prior to 149.0.7827.53 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical)

AnalysisAI

Sandbox escape in Google Chrome versions prior to 149.0.7827.53 allows remote attackers who have already compromised the renderer process to potentially break out of the sandbox via a stack buffer overflow in the GPU component triggered by a crafted HTML page. Chromium rates this as Critical severity, and while no public exploit has been identified at time of analysis, the vendor has released a patched stable channel build addressing the issue.

Technical ContextAI

The flaw is a CWE-121 Stack-based Buffer Overflow within Chrome's GPU process, which handles graphics acceleration and is one of the privileged helper processes Chrome uses as part of its multi-process sandbox architecture. The GPU process accepts IPC messages from less-privileged renderer processes, and a memory-safety bug here is particularly dangerous because the GPU process historically runs with broader system access than the renderer sandbox permits, making it a frequent target for sandbox-escape chains. The affected codebase is Chromium (the upstream engine for Chrome and many derivatives such as Edge, Brave, Opera, and Electron applications), so the impact extends beyond Google's own browser distribution.

RemediationAI

Apply the vendor-released patch by updating Google Chrome to version 149.0.7827.53 or later on all desktop platforms (Windows, macOS, Linux) per the Chrome Releases advisory at https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop.html; in managed environments, force a relaunch through enterprise update policy rather than relying on user-initiated restarts, since the fix is only active after the browser process restarts. Administrators of Chromium-derivative browsers (Edge, Brave, Opera, Vivaldi) and Electron-based applications should monitor their respective vendors and update once a build incorporating the Chromium 149.0.7827.53 merge is shipped. As a compensating control until patching completes, consider enforcing the SitePerProcess and IsolateOrigins enterprise policies to strengthen renderer isolation (no functional downside for most workloads), and on Windows additionally enable the GPU process's app-container/win32k lockdown mitigations via RendererCodeIntegrity-style policies where supported - note that disabling hardware acceleration (chrome://settings 'Use graphics acceleration when available') will not eliminate the GPU process and is not a reliable workaround.