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.
3 steps from start to impact.
Land renderer compromise
- Victim browses attacker-controlled content
- A separate renderer-compromise bug exists and is successfully exploited
- Target is Chrome on Windows
- 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
Trigger Dawn input-validation flaw
- Compromised renderer can reach the vulnerable Dawn path
- Victim remains on a vulnerable Chrome build before 149.0.7827.53
- 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
Bypass cross-origin boundary
- Interesting target data is present in the victim browser session
- Cross-origin data is accessible through the vulnerable path
- Attacker can exfiltrate leaked material
- 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
The supporting signals.
| In-the-wild status | No public active exploitation evidence found in reviewed primary sources. NVD and GHSA describe the issue, but neither cites in-the-wild abuse. |
|---|---|
| KEV status | Not 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 availability | No public PoC or exploit repo found in reviewed primary sources for CVE-2026-10968 / GHSA-55cp-fwh4-vq8q. That lowers opportunistic abuse pressure. |
| EPSS | 0.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 meaning | CVSS: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 versions | Google Chrome on Windows before 149.0.7827.53. NVD explicitly scopes this CVE to Windows. |
| Fixed version | Patched in Chrome 149.0.7827.53 for Windows. Google pushed this in the Early Stable Update for Desktop on 2026-05-29. |
| Exposure model | This 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 timeline | User-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 credit | No public researcher credit located in the reviewed primary sources for this specific CVE. Chrome often withholds bug details until broad patch uptake. |
noisgate verdict.
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.
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.
What to do — in priority order.
- Enforce Chrome auto-update — Make sure Windows Chrome is not pinned below
149.0.7827.53and 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. - 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.
- 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.
- 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.
- 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.
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.
# 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
If you remember one thing.
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
- NVD CVE-2026-10968
- GitHub Advisory Database GHSA-55cp-fwh4-vq8q
- Chrome Releases - Early Stable Update for Desktop
- Chromium Docs - Threat Model And Defenses Against Compromised Renderers
- Chromium - Chrome sandbox diagnostics for Windows
- Chrome Enterprise Help - Manage Chrome updates (Windows)
- FIRST EPSS API
- CISA Known Exploited Vulnerabilities Catalog
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.