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

CVE-2026-7336 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.0%.

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

A remote code execution flaw in Google Chrome's WebRTC component (CVE-2026-7336) affects all users on versions prior to 147.0.7727.138.. A patch is available.

How to fix or mitigate CVE-2026-7336?

Within 24 hours, audit all Chrome installations to identify versions prior to 147.0.7727.138 and verify patch 147.0.7727.138 availability across your distribution channels. Within 7 days, deploy the patch to high-risk systems including executive and sensitive-access user groups, prioritizing devices exposed to external web content. Within 30 days, complete enterprise-wide deployment of Chrome 147.0.7727.138 or later across all managed devices to achieve full coverage.

Google Chrome CVE-2026-7336

HIGH

Use After Free (CWE-416)

2026-04-28 Chrome

RCE Denial Of Service Google Use After Free Memory Corruption

8.8

CVSS 3.1 · Vendor: Chrome

Severity by source

Vendor (Chrome) 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 with mandatory user interaction (UI:R), no auth (PR:N); code execution stays in-sandbox so scope is Unchanged, with 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

8.8 HIGH

qualitative

Primary rating from Vendor (Chrome).

CVSS VectorVendor: Chrome

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 24, 2026 - 03:50 vuln.today

CVSS changed

Apr 29, 2026 - 13:23 NVD

8.8 (HIGH)

Patch released

Apr 29, 2026 - 00:30 nvd

Patch available

CVE Published

Apr 28, 2026 - 22:36 nvd

HIGH 8.8

DescriptionCVE.org

Use after free in WebRTC in Google Chrome prior to 147.0.7727.138 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)

AnalysisAI

Remote code execution in Google Chrome's WebRTC component (versions prior to 147.0.7727.138) allows a remote attacker to run arbitrary code within the renderer sandbox by luring a victim to a crafted HTML page. The flaw is a use-after-free memory corruption reported by Google's own Chrome team; there is no public exploit identified at time of analysis and it is not listed in CISA KEV. EPSS is very low (0.01%), and CISA SSVC scores exploitation as 'none', indicating no observed exploitation despite the high technical severity.

Technical ContextAI

The vulnerability resides in WebRTC, the real-time communication stack built into Chromium that handles peer-to-peer audio/video and data channels directly from web content. It is a CWE-416 Use-After-Free: a heap object is freed while a dangling reference remains reachable, and subsequent access to that stale pointer lets an attacker corrupt memory and hijack control flow. Because WebRTC processing runs inside the sandboxed renderer process, the described code execution is confined to that sandbox rather than the host OS. The affected component is identified by CPE cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:*, covering the Chrome desktop application across all versions below the fixed build.

RemediationAI

Vendor-released patch: update Google Chrome to 147.0.7727.138 or later via the Chrome Stable channel; most installations will receive this automatically, but administrators should force-restart the browser to complete the update since Chrome only applies pending updates on relaunch, and verify the running version under chrome://settings/help. Downstream Chromium consumers should apply the corresponding Red Hat and SUSE package updates as they are published. There is no supported configuration-level workaround that fully neutralizes a WebRTC memory bug, but until patching completes you can reduce exposure by restricting untrusted browsing and, in managed environments, disabling WebRTC where it is not needed via enterprise policy (e.g. WebRtcAllowLegacyTLSProtocols/URL-based WebRTC restrictions or blocking peer connections) - with the trade-off that this breaks video conferencing and other real-time features. Refer to the vendor advisory at https://chromereleases.googleblog.com/2026/04/stable-channel-update-for-desktop_28.html.