← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11075 · CWE-125 · Disclosed 2026-06-04

Out of bounds read in V8 in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Wide product, narrow impact: this is a browser-session info leak, not a fleet-burning Chrome emergency"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on a malicious page

The attacker needs a victim to render hostile HTML/JavaScript in Chrome, typically via phishing, malvertising, SEO poisoning, or a compromised legitimate site. The weaponized tool here is just the browser itself plus a crafted web payload; there is no server-side foothold requirement.
Conditions required:
  • Victim is using a vulnerable Chrome build
  • Victim opens attacker-controlled content in Chrome
  • JavaScript execution is allowed
Where this breaks in practice:
  • User interaction is mandatory
  • Email/web filtering and Safe Browsing reduce successful delivery
  • Many enterprises force auto-update on browsers, shrinking dwell time
Detection/coverage: Secure web gateways and phishing telemetry may catch delivery, but vuln scanners do not see the exploit attempt itself.
STEP 02

Trigger the V8 out-of-bounds read primitive

The malicious script drives V8 into an out-of-bounds read condition through a crafted sequence of JavaScript operations. The practical weapon is a custom exploit harness running in the renderer; reliability usually depends on exact engine build, allocator behavior, and architecture.
Conditions required:
  • Precise bug trigger works against the target's V8 build
  • No exploit-breaking hardening or version mismatch
Where this breaks in practice:
  • 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
Detection/coverage: EDR rarely gives crisp signatures for in-browser memory disclosure; crash telemetry and browser error reporting are more realistic indicators.
STEP 03

Extract useful data from renderer memory

The attacker must convert raw out-of-bounds reads into *valuable* secrets: tokens, page content, cross-origin residues, or layout/ASLR disclosures useful for chaining. This is the hard part operationally; modern Chrome isolates sites and sandboxes renderers, which sharply limits the accessible blast radius.
Conditions required:
  • Sensitive material is present in reachable browser-process memory
  • The attacker can parse and stabilize leaked memory contents
Where this breaks in practice:
  • 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
Detection/coverage: Little direct scanner coverage. Detection is mostly inferential through anomalous browser behavior, crash spikes, or suspicious follow-on traffic.
STEP 04

Exfiltrate the leaked material

If the attacker gets readable secrets, they still need to send them off-box using normal web requests such as fetch, XHR, or beacon-style traffic. At that point the outcome is data leakage from a user session, not domain-wide compromise.
Conditions required:
  • Outbound network path from the browser to attacker infrastructure
  • Leaked data is actually useful to the attacker
Where this breaks in practice:
  • 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
Detection/coverage: Proxy logs, DNS telemetry, and DLP can sometimes catch exfil, but signatures are weak because traffic looks like ordinary browser traffic.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence found in reviewed sources. Not cited as actively exploited, and no reviewed advisory described exploitation before disclosure.
KEV statusNot KEV-listed as of the reviewed CISA catalog sources; no CISA date-added entry located for CVE-2026-11075.
PoC availabilityNo public PoC found in reviewed sources. That matters because browser memory-disclosure bugs are harder to operationalize than generic server-side flaws.
EPSS0.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 vectorCVSS: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 versionsChrome 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 versionsPatch 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 realityInternet-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 timelineUser-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 creditNot 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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.9/10)

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.

HIGH Affected version floor and vendor baseline
MEDIUM Real-world exploitability assessment for the standalone leak primitive
MEDIUM Absence of public PoC / active exploitation in reviewed sources

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.00035 EPSS 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.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Make sure managed Chrome channels are actually reaching 149.0.7827.53/54 or 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.
  2. 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).
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# 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
}
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not burn an emergency CAB on this one: pull browser inventory, confirm which endpoints are still below 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

  1. Chrome Releases - Early Stable Update for Desktop
  2. Canadian Centre for Cyber Security AV26-544
  3. CISA Known Exploited Vulnerabilities Catalog
  4. FIRST EPSS project
  5. FIRST EPSS API
  6. Quanteta CVE tracker entry set including CVE-2026-11075
  7. Chrome for Testing availability index
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.