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

CVE-2026-11074 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 CVE-2026-11074?

Google Chrome on Linux systems running versions prior to 149.0.7827.53 are vulnerable to remote code execution via the WebRTC component, exposing any user to complete endpoint compromise through…. A patch is available.

How to fix or mitigate CVE-2026-11074?

Within 24 hours: Identify all Chrome installations on Linux assets using endpoint management tools. Within 7 days: Push update to Chrome 149.0.7827.53 or later via enterprise software distribution; enable mandatory auto-update policies to prevent version regression. Within 30 days: Confirm 100% patch adoption via compliance reporting; review security logs for exploitation attempts correlated to CVE-2026-11074.

Google Chrome CVE-2026-11074

EUVD-2026-34522 HIGH

Use After Free (CWE-416)

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

GHSA-cpj9-x7fc-h34f

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

High

Disputed · 8.8 NVD

Severity by source

Sources disagree (Medium–Critical)

NVD PRIMARY

8.8 HIGH

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

SUSE

CRITICAL

qualitative

Red Hat

9.6 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 VectorNVD

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jun 05, 2026 - 03:06 vuln.today

CVSS changed

Jun 05, 2026 - 02:22 NVD

8.8 (HIGH)

CVE Published

Jun 04, 2026 - 23:17 nvd

UNKNOWN (no severity yet)

CVE Published

Jun 04, 2026 - 23:17 nvd

HIGH 8.8

DescriptionCVE.org

Use after free in WebRTC in Google Chrome on Linux prior to 149.0.7827.53 allowed a remote attacker to execute arbitrary code via a crafted HTML page. (Chromium security severity: Medium)

AnalysisAI

Remote code execution in Google Chrome on Linux prior to version 149.0.7827.53 allows a remote attacker to exploit a use-after-free condition in the WebRTC component via a crafted HTML page. The flaw carries a CVSS 3.1 score of 8.8 with user interaction required, and while no public exploit has been identified at time of analysis, Chromium-class memory corruption bugs in WebRTC are historically high-value targets. Google has released a patched stable channel build, and Chromium itself rates the severity as Medium despite the higher NVD CVSS.

Technical ContextAI

The vulnerability resides in WebRTC, the real-time communication stack embedded in Chromium that handles audio, video, and peer-to-peer data channels through protocols such as SRTP, ICE, DTLS, and SCTP. CWE-416 (Use After Free) indicates the renderer or WebRTC subsystem references heap memory after it has been freed, which an attacker can groom to achieve arbitrary read/write primitives and ultimately code execution within the sandboxed renderer process. Because WebRTC parses and processes attacker-influenced media and signaling data automatically when a page is loaded, the attack surface is broad and reachable from any web origin that can persuade the browser to initialize a peer connection. The affected component is specifically the Linux build of Chrome stable channel prior to 149.0.7827.53, per the Chrome Releases advisory.

RemediationAI

Upgrade Google Chrome on Linux to version 149.0.7827.53 or later, which is the vendor-released patch documented in the Chrome Releases stable channel update at https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop.html and tracked in Chromium issue https://issues.chromium.org/issues/499587071. Enterprise fleets should force-restart browsers to ensure the update is loaded since Chrome only applies patched binaries on relaunch. If patching cannot be performed immediately, compensating controls include disabling WebRTC via the WebRtcAllowLegacyTLSProtocols and URLBlocklist enterprise policies or by deploying an extension that blocks getUserMedia/RTCPeerConnection APIs - note this will break Google Meet, Jitsi, Discord web, and most video-conferencing sites. Network-level mitigations such as blocking STUN/TURN (UDP 3478, TCP 5349) at egress will not prevent exploitation since the UAF triggers during local WebRTC object handling, not on the wire.