This is a peephole in one apartment window, not a master key to the whole building
CVE-2026-11075 is an out-of-bounds read in Chrome's V8 JavaScript engine. In practice, that means a malicious page can try to coerce the browser into reading memory it should not, potentially disclosing sensitive data from the affected browser process. Based on the vendor advisory trail, affected builds are Chrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows and macOS, with disclosure on 2026-06-04 and rollout beginning in late May/early June 2026.
Google's MEDIUM 6.5 label is technically defensible in CVSS terms, but it overstates operational urgency for enterprise patch queues. This is *remote* but still requires user interaction, delivers *confidentiality-only* impact, and remains boxed inside modern browser protections unless paired with another bug; with no KEV listing, no exploitation evidence in reviewed sources, and a very low EPSS, this belongs in routine browser hygiene rather than emergency change windows.
4 steps from start to impact.
Land the user on a malicious page
- Victim is using a vulnerable Chrome build
- Victim opens attacker-controlled content in Chrome
- JavaScript execution is allowed
- User interaction is mandatory
- Email/web filtering and Safe Browsing reduce successful delivery
- Many enterprises force auto-update on browsers, shrinking dwell time
Trigger the V8 out-of-bounds read primitive
- Precise bug trigger works against the target's V8 build
- No exploit-breaking hardening or version mismatch
- Browser memory bugs are notoriously version-sensitive
- A read primitive is less immediately useful than a write or UAF-to-RCE chain
- Renderer crashes are noisy and reduce repeatability
Extract useful data from renderer memory
- Sensitive material is present in reachable browser-process memory
- The attacker can parse and stabilize leaked memory contents
- Site Isolation and process separation limit what one renderer can see
- Useful secrets may not be resident when the exploit fires
- Memory disclosure alone does not grant code execution or host compromise
Exfiltrate the leaked material
fetch, XHR, or beacon-style traffic. At that point the outcome is data leakage from a user session, not domain-wide compromise.- Outbound network path from the browser to attacker infrastructure
- Leaked data is actually useful to the attacker
- CSP, network egress controls, and browser isolation can reduce exfil paths
- Many leaks are low-value or non-deterministic
- Impact is typically scoped to one user and one session
The supporting signals.
| In-the-wild status | No evidence found in reviewed sources. Not cited as actively exploited, and no reviewed advisory described exploitation before disclosure. |
|---|---|
| KEV status | Not KEV-listed as of the reviewed CISA catalog sources; no CISA date-added entry located for CVE-2026-11075. |
| PoC availability | No public PoC found in reviewed sources. That matters because browser memory-disclosure bugs are harder to operationalize than generic server-side flaws. |
| EPSS | 0.00035 from the user-supplied intel, which is *extremely low* expected near-term exploitation probability. FIRST's EPSS project and API are the canonical references. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — remote delivery and no privileges help the score, but UI:R and *confidentiality-only* impact are the real-world brakes. |
| Affected versions | Chrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows/macOS, based on Google and downstream advisories. |
| Fixed versions | Patch floor is 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS. Enterprises using Chrome rings should verify those builds actually landed, not just that auto-update is enabled. |
| Exposure / scanning reality | Internet-wide scanning is basically irrelevant here. This is client software, so Shodan/Censys/FOFA do not tell you your exposure; your CMDB, endpoint inventory, or browser-management console does. |
| Disclosure timeline | User-supplied disclosure date is 2026-06-04; Google began early stable rollout for 149.0.7827.53/.54 on 2026-05-29, and the Canadian Cyber Centre published downstream notice on 2026-06-03. |
| Researcher / reporting credit | Not clearly attributed in the reviewed sources for this specific CVE. If you need bounty-credit attribution, wait for the more detailed Chromium-side publication trail. |
noisgate verdict.
The decisive factor is that this is a *user-driven, confidentiality-only browser-session leak* rather than a remote code execution path. Chrome is everywhere, but the blast radius here is usually one renderer, one user, one session, with no evidence in reviewed sources that attackers are already cashing it in at scale.
Why this verdict
- Requires user interaction — the attacker still has to get the victim to open hostile content, which immediately narrows reachable population versus a wormable or service-side flaw.
- Confidentiality-only impact — there is no integrity or availability loss in the disclosed baseline, and no direct host compromise without chaining.
- Browser isolation cuts blast radius — Site Isolation, renderer sandboxing, and process separation mean the bug is not a straight line to domain compromise even if triggered.
- No public exploitation signal — no KEV entry, no reviewed exploitation reports, and a very low
0.00035EPSS all push this down. - Version inventory beats perimeter exposure — this is not externally enumerable like a VPN or edge appliance, so the reachable attack surface is governed by user behavior and update lag, not internet exposure.
Why not higher?
A higher rating would require one of three amplifiers: active exploitation, an accompanying sandbox escape/RCE path, or evidence that the info leak reliably exposes high-value secrets across normal enterprise browsing. None of those are present in the reviewed evidence. On its own, an out-of-bounds read in a modern browser is usually a *chain component* or scoped data leak, not a stand-alone crisis.
Why not lower?
It is still remotely deliverable through ordinary web content and Chrome is massively deployed, so the affected population is inherently large. Also, memory disclosure in V8 can become strategically useful when paired with another browser bug, so writing it off as pure noise would be too optimistic.
What to do — in priority order.
- Enforce browser auto-update — Make sure managed Chrome channels are actually reaching
149.0.7827.53/54or later and that stalled endpoints are flagged. For a LOW verdict there is no SLA (treat as backlog hygiene), so do this in your normal browser-maintenance motion rather than an emergency change. - Reduce risky web delivery — Tighten phishing-resistant web controls: Safe Browsing policy, malicious-site filtering, and ad/malvertising blocking where your enterprise stack supports it. This directly attacks the required user-navigation step; for LOW, treat it as routine posture work with no SLA (backlog hygiene).
- Inventory vulnerable builds — Pull endpoint version telemetry from your browser-management platform, EDR, or software inventory and isolate systems stuck below the fixed builds. Because this is LOW, there is no mitigation SLA to race against; use your next normal reporting cycle.
- Watch browser crash spikes — Feed Chrome crash telemetry and abnormal renderer fault rates into detection review, especially if tied to suspicious referrers or newly seen domains. This will not reliably detect exploitation, but it is one of the few practical tripwires for browser memory bugs; schedule it as backlog hygiene for a LOW finding.
- Perimeter vulnerability scanning — it does not tell you which endpoints have a vulnerable local browser build.
- WAF rules — there is no server-side request pattern to block at your edge because exploitation runs inside the user's browser.
- MFA — useful generally, but it does not prevent triggering the memory disclosure bug itself.
- Generic 'patch browsers eventually' policy without version validation — auto-update assumptions routinely fail on paused devices, VDI images, and restricted service accounts.
Crowdsourced verification payload.
Run this on the target Windows endpoint or through your EDR/live-response shell. Invoke it with powershell -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-11075.ps1; standard user rights are usually enough because it only reads file metadata from common Chrome install paths.
# check-chrome-cve-2026-11075.ps1
# Purpose: Determine whether Google Chrome on a Windows host is vulnerable to CVE-2026-11075
# Logic: Any Chrome version lower than 149.0.7827.53 is considered VULNERABLE
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
$ErrorActionPreference = 'SilentlyContinue'
function Get-ChromeCandidates {
$paths = @(
"$Env:ProgramFiles\Google\Chrome\Application\chrome.exe",
"$Env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
"$Env:LocalAppData\Google\Chrome\Application\chrome.exe"
)
$existing = @()
foreach ($p in $paths) {
if ($p -and (Test-Path $p)) {
$existing += $p
}
}
return $existing
}
function Get-FileVersionString($path) {
try {
return (Get-Item $path).VersionInfo.FileVersion
}
catch {
return $null
}
}
function Normalize-Version([string]$v) {
if (-not $v) { return $null }
$clean = ($v -split '\s+')[0].Trim()
try {
return [version]$clean
}
catch {
return $null
}
}
$fixedVersion = [version]'149.0.7827.53'
$candidates = Get-ChromeCandidates
if (-not $candidates -or $candidates.Count -eq 0) {
Write-Output 'UNKNOWN - Google Chrome executable not found in common install paths.'
exit 2
}
$results = @()
foreach ($chromePath in $candidates) {
$raw = Get-FileVersionString -path $chromePath
$ver = Normalize-Version -v $raw
if ($ver -eq $null) {
$results += [pscustomobject]@{
Path = $chromePath
RawVersion = $raw
ParsedVersion = $null
Status = 'UNKNOWN'
}
continue
}
$status = if ($ver -lt $fixedVersion) { 'VULNERABLE' } else { 'PATCHED' }
$results += [pscustomobject]@{
Path = $chromePath
RawVersion = $raw
ParsedVersion = $ver.ToString()
Status = $status
}
}
$results | ForEach-Object {
Write-Output ("{0} - {1} - {2}" -f $_.Status, $_.ParsedVersion, $_.Path)
}
if ($results.Status -contains 'VULNERABLE') {
exit 1
}
elseif ($results.Status -contains 'PATCHED') {
exit 0
}
else {
Write-Output 'UNKNOWN - Unable to parse any Chrome version.'
exit 2
}
If you remember one thing.
149.0.7827.53/54, and fold them into your normal Chrome servicing wave. For a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA — treat it as backlog hygiene — but because Chrome is so widespread you should still close version gaps in your next routine browser update cycle rather than letting stragglers drift for quarters.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.