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