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

Insufficient validation of untrusted input in Dawn in Google Chrome on Windows prior to 149

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

This is a second lock failing after the burglar is already inside the first room

CVE-2026-10968 is an improper input validation bug in Chrome's Dawn component on Windows that affects Google Chrome versions before 149.0.7827.53. The bug does not give an attacker first-hop code execution by itself; it lets an attacker who has already compromised the renderer process use a crafted HTML page to leak cross-origin data, meaning this is a browser security-boundary failure after an earlier compromise stage has already happened.

Google/NVD rated it HIGH 7.4, which is fair in a pure browser-chain sense because Chrome explicitly models defense against compromised renderers. For enterprise patch triage, though, that overstates the Monday-morning urgency: the decisive friction is the prerequisite of a pre-compromised renderer, which means the attacker already landed another browser exploit or equivalent renderer-native code execution first. That pushes this down from stand-alone urgent patching into chain-hardening.

"Serious only as a chain component: this is a post-renderer-compromise data leak, not an initial-access bug"
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land renderer compromise

The attacker first needs native code execution or equivalent arbitrary control inside Chrome's sandboxed renderer. In practice that usually means chaining a separate renderer memory-corruption bug, logic bug, or exploit delivered through a malicious page. Weaponized tool: custom renderer exploit chain; no public named tool or repo was identified in primary sources for this CVE.
Conditions required:
  • Victim browses attacker-controlled content
  • A separate renderer-compromise bug exists and is successfully exploited
  • Target is Chrome on Windows
Where this breaks in practice:
  • This CVE is not the initial access bug
  • Modern Chrome hardening, site isolation, and exploit mitigations make renderer-native compromise non-trivial
  • Enterprise EDR/browser telemetry may catch the precursor exploit or crash-heavy exploit development
Detection/coverage: Standard vuln scanners will flag vulnerable Chrome versions, but they generally cannot prove the renderer-compromise prerequisite. Detection value is mostly from browser version inventory plus exploit/crash telemetry.
STEP 02

Trigger Dawn input-validation flaw

After renderer control, the attacker uses a crafted HTML page to drive the vulnerable Dawn code path. The bug is in a component Chrome treats as part of its defense-in-depth boundary against compromised renderers, so exploitation is about abusing trust boundaries after sandboxed execution is already achieved. Weaponized tool: crafted HTML/JS exploit content; no public PoC found in reviewed primary sources.
Conditions required:
  • Compromised renderer can reach the vulnerable Dawn path
  • Victim remains on a vulnerable Chrome build before 149.0.7827.53
Where this breaks in practice:
  • Windows-only scope narrows the reachable fleet
  • The vulnerable code path may not be reliably reachable in every browsing session
  • Bug details remain restricted, limiting opportunistic weaponization
Detection/coverage: Version-based detection is good; exploit-sequence detection is weak unless you have detailed Chrome/EDR telemetry or sandbox violation instrumentation.
STEP 03

Bypass cross-origin boundary

Successful exploitation leaks data that should remain isolated across origins. That makes this useful for stealing tokens, page data, or sensitive cross-site content accessible within the browser context, but it is still a confidentiality issue rather than host takeover. Weaponized tool: attacker-controlled collection endpoint and browser-resident exfil logic.
Conditions required:
  • Interesting target data is present in the victim browser session
  • Cross-origin data is accessible through the vulnerable path
  • Attacker can exfiltrate leaked material
Where this breaks in practice:
  • Impact depends on what the user is actively authenticated to
  • This does not itself provide persistence, OS privilege escalation, or ransomware-style blast radius
  • Site Isolation and other browser boundaries reduce some post-exploit options even after renderer compromise
Detection/coverage: Network detection is weak unless exfil is noisy. Session theft indicators may appear only downstream in IdP, SaaS, or UEBA telemetry.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public active exploitation evidence found in reviewed primary sources. NVD and GHSA describe the issue, but neither cites in-the-wild abuse.
KEV statusNot KEV-listed per the user's intel and no matching entry was identified from CISA KEV catalog review. This is an inference from absence, not a direct CISA statement for this specific CVE.
PoC availabilityNo public PoC or exploit repo found in reviewed primary sources for CVE-2026-10968 / GHSA-55cp-fwh4-vq8q. That lowers opportunistic abuse pressure.
EPSS0.00047 (~0.047%) from the user-supplied intel, which is extremely low and consistent with a niche post-compromise browser chain component rather than mass exploitation.
CVSS vector meaningCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N means remote delivery with user interaction and high confidentiality impact, but the vector does not express the real-world prerequisite that the renderer must already be compromised. That hidden prerequisite is why noisgate scores it down.
Affected versionsGoogle Chrome on Windows before 149.0.7827.53. NVD explicitly scopes this CVE to Windows.
Fixed versionPatched in Chrome 149.0.7827.53 for Windows. Google pushed this in the Early Stable Update for Desktop on 2026-05-29.
Exposure modelThis is endpoint-side exposure, not an internet-facing service. There is no meaningful Shodan/Censys-style external attack-surface measurement because Chrome browsers are not directly exposed as scan targets.
Disclosure timelineUser-provided disclosure date is 2026-06-05. NVD shows the CVE record was received on 2026-06-04 and enriched on 2026-06-05.
Reporter / research creditNo public researcher credit located in the reviewed primary sources for this specific CVE. Chrome often withholds bug details until broad patch uptake.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.6/10)

The single factor that drives this into MEDIUM is the requirement for a pre-compromised renderer. That means the attacker already cleared Chrome's first major exploitation barrier, so this CVE is best treated as a post-initial-compromise browser chain amplifier, not a stand-alone internet-scale emergency.

HIGH Severity downgrade based on the renderer-compromise prerequisite
MEDIUM Assessment of exploitation likelihood due to limited public bug detail

Why this verdict

  • Major downward adjustment: requires compromised renderer first — attacker position is not unauthenticated remote in the real world; it implies a prior browser exploit or equivalent native control inside the sandbox.
  • Windows-only scope narrows the population — this is not your whole Chrome estate if you run mixed Windows/macOS/Linux fleets.
  • Impact is data leakage, not host takeover — confidentiality can be serious, but there is no direct integrity or availability impact and no evidence here of sandbox escape or persistence.
  • No KEV, no public exploitation, ultra-low EPSS — current threat pressure looks low compared with browser bugs that are actively chained in the wild.
  • Scanner visibility is easy, exploitability is not — version inventory will show exposure, but the real attack path assumes another exploit stage that most fleets will not routinely face.

Why not higher?

If this were a stand-alone renderer RCE, sandbox escape, or KEV-listed browser zero-day, the answer would move up fast. But this CVE needs a prior renderer compromise and then yields cross-origin data exposure rather than direct system control, which materially limits urgency for broad fleet triage.

Why not lower?

It still matters because Chrome explicitly treats compromised renderers as part of its threat model, and enterprises run a lot of authenticated SaaS sessions in browsers. On high-value users, a post-compromise cross-origin leak can still translate into token theft, data exposure, and follow-on access.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update — Make sure Windows Chrome is not pinned below 149.0.7827.53 and that Google Update policies allow normal rollout. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this is a routine browser update you should absorb well before that.
  2. Prioritize high-value user rings — Push patched Chrome first to admins, executives, developers, and users with privileged SaaS access, because the real business risk is session and data exposure after a chained browser compromise. For MEDIUM, there is no separate mitigation deadline; use your standard browser deployment cadence inside the 365-day remediation window.
  3. Harden browser exploit telemetry — Increase attention on Chrome crashes, renderer exploit signals, suspicious child-process behavior, and unusual browser-to-EDR correlations. This does not replace patching, but it is the right control for a bug whose main danger appears only after another exploit stage.
  4. Reduce risky browsing paths for sensitive roles — Use isolation, application control, or stricter web filtering for admin and finance populations where feasible. That cuts the chance of the precursor renderer exploit that this CVE depends on.
What doesn't work
  • A perimeter firewall doesn't help much; this is delivered through normal user browsing, not inbound service exposure.
  • MFA does not stop the bug itself; it may reduce downstream account abuse, but it won't prevent cross-origin data leakage inside the browser session.
  • Network vuln scanning alone is insufficient; scanners can flag versions, but they cannot model the crucial prerequisite that another exploit has already compromised the renderer.
06 · Verification

Crowdsourced verification payload.

Run this on the target Windows endpoint or via your endpoint management tool. Invoke with powershell -ExecutionPolicy Bypass -File .\check-chrome-cve-2026-10968.ps1; local admin is not required for version checks, though admin helps if you want all install paths and per-user locations reliably enumerated.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# check-chrome-cve-2026-10968.ps1

# Purpose: Detect whether Google Chrome on Windows is vulnerable to CVE-2026-10968

# Vulnerable if installed version is less than 149.0.7827.53

# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN


$ErrorActionPreference = 'SilentlyContinue'
$fixedVersion = [version]'149.0.7827.53'

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"
    )

    $regPaths = @(
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
        'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
        'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe'
    )

    foreach ($rp in $regPaths) {
        $reg = Get-ItemProperty -Path $rp
        if ($reg -and $reg.'(default)') { $paths += $reg.'(default)' }
        if ($reg -and $reg.Path) { $paths += (Join-Path $reg.Path 'chrome.exe') }
    }

    $paths | Where-Object { $_ -and (Test-Path $_) } | Select-Object -Unique
}

function Get-FileVersion([string]$path) {
    try {
        return [version](Get-Item $path).VersionInfo.FileVersion
    } catch {
        return $null
    }
}

$candidates = Get-ChromeCandidates
if (-not $candidates -or $candidates.Count -eq 0) {
    Write-Output 'UNKNOWN: chrome.exe not found in common paths or registry.'
    exit 2
}

$results = @()
foreach ($c in $candidates) {
    $ver = Get-FileVersion -path $c
    if ($ver) {
        $results += [pscustomobject]@{
            Path = $c
            Version = $ver
            Status = if ($ver -lt $fixedVersion) { 'VULNERABLE' } else { 'PATCHED' }
        }
    }
}

if (-not $results -or $results.Count -eq 0) {
    Write-Output 'UNKNOWN: Chrome located, but version could not be determined.'
    exit 2
}

$results | Sort-Object Path | ForEach-Object {
    Write-Output ("{0}: {1} [{2}]" -f $_.Status, $_.Path, $_.Version)
}

if ($results.Status -contains 'VULNERABLE') {
    Write-Output 'VULNERABLE'
    exit 1
}

Write-Output 'PATCHED'
exit 0
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: query your Windows fleet for Chrome versions below 149.0.7827.53, verify update policies are not pinning old builds, and fold this into your normal browser rollout rings. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window under the noisgate remediation SLA, but operationally this should still ride the next routine Chrome wave because it is a useful post-compromise chain link for high-value browser sessions even though it is not an internet-scale emergency on its own.

Sources

  1. NVD CVE-2026-10968
  2. GitHub Advisory Database GHSA-55cp-fwh4-vq8q
  3. Chrome Releases - Early Stable Update for Desktop
  4. Chromium Docs - Threat Model And Defenses Against Compromised Renderers
  5. Chromium - Chrome sandbox diagnostics for Windows
  6. Chrome Enterprise Help - Manage Chrome updates (Windows)
  7. FIRST EPSS API
  8. CISA Known Exploited Vulnerabilities Catalog
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.