This is a peep-hole in every employee browser window, not a battering ram at the front door
CVE-2026-10992 is an *insufficient data validation* flaw in Chrome's Animation component that affects Chrome desktop builds prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/54 on Windows and macOS. Per the vendor description, a remote attacker can use a crafted HTML page to obtain potentially sensitive information, which puts this in the browser-side info-disclosure bucket rather than code-exec or sandbox-escape territory.
Google's MEDIUM 6.5 baseline is technically defensible, but it undersells one operational reality: this sits in a browser, the one app your users point at hostile content all day. The downgrade pressures are real — user interaction is required, there is no current KEV listing, no public exploit is evident, and the impact is confidentiality-only — but the exposure population is enormous and the attacker does not need auth, internal network position, or a prior foothold, so this lands a notch hotter for enterprise patch triage than a generic medium.
3 steps from start to impact.
Deliver a malicious page
- Target runs Chrome below
149.0.7827.53on Linux or below149.0.7827.53/54on Windows/macOS - Attacker can get the user to load attacker-controlled web content
- Requires user interaction (
UI:R), so it is not a drive-by against an unopened browser - Email gateways, safe browsing, DNS filtering, and web isolation can reduce reach to the malicious page
Trigger the vulnerable Animation path
- The page must exercise the affected code path in the victim's browser build
- The bug must be reachable in the user's runtime configuration
- Modern browser hardening, process isolation, and allocator behavior can make info leaks noisy or less deterministic
- Ad blockers, script controls, and site isolation can reduce reliability depending on exact trigger mechanics
Exfiltrate disclosed data
- Useful sensitive data must be present in memory or otherwise exposed at trigger time
- The attacker must be able to receive the leaked material back through browser-controlled channels
- Info leaks are often partial and timing-sensitive; many runs return junk or low-value data
- Confidentiality impact may stay user-session scoped and may not translate into broader host compromise
The supporting signals.
| In-the-wild status | No evidence of active exploitation found in the reviewed authoritative sources; not listed in CISA KEV. |
|---|---|
| KEV status | Not present in the CISA Known Exploited Vulnerabilities Catalog as reviewed. |
| Public PoC | No public GitHub or researcher PoC surfaced in source review. That lowers near-term commoditization pressure. |
| EPSS | User-supplied EPSS is 0.00035 (~0.035% estimated exploitation probability over 30 days). That is *very low* and argues against panic patching absent other intel. |
| EPSS percentile | Not directly verified from FIRST API output in the reviewed sources. *Inference:* with an EPSS this low, the percentile is likely on the lower end of the corpus, but I am not asserting an exact number. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — remote and low-complexity, but requires user interaction and has confidentiality-only impact. |
| Affected versions | Chrome desktop versions prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/54 on Windows and macOS per Google's June 2, 2026 stable release and the Canadian Cyber Centre advisory. |
| Fixed versions | Fixed in 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS). Early stable for a subset of Windows/macOS users shipped on 2026-05-29; broad stable shipped on 2026-06-02. |
| Disclosure / reporting | Google's stable channel notes mark CVE-2026-10992 as reported by heapracer (@heapracer) on 2026-03-17; public stable disclosure landed on 2026-06-02 and user-supplied disclosure metadata says 2026-06-04. |
| Scanning / exposure reality | Shodan/Censys/FOFA-style exposure counting is not meaningful here because this is client-side browser software, not an internet-listening service. The relevant exposure fact is install-base ubiquity: Chrome is broadly deployed across enterprise endpoints and directly exposed to untrusted web content. |
noisgate verdict.
The decisive amplifier is reachability at internet scale on end-user browsers: an unauthenticated attacker only needs a user to load a page, which is a normal daily action, not a special prerequisite. I upgraded this because the vulnerable population is huge and directly faces hostile content, even though the bug is 'only' an information disclosure and current exploitation evidence is weak.
Why this verdict
- Upgrade for exposure population: Chrome is one of the most exposed applications in the fleet; hostile web content reaches it every day, so
AV:N/PR:Nmatters more here than in niche client software. - Downward pressure from required user action:
UI:Rmeans this is not wormable and not an ambient background exploit; the attacker still needs a lure, compromised site, or malvertising path. - Downward pressure from impact type: this is a confidentiality leak, not RCE, not sandbox escape, and not an integrity/availability event, which keeps it out of the critical bucket.
- Downward pressure from threat intel: no KEV listing, no reviewed evidence of active exploitation, and no public PoC reduce the odds of mass weaponization this week.
- Slight upward pressure over vendor score: broad enterprise blast radius at the *fleet* level offsets some of the single-host technical modesty; even a medium-grade browser leak becomes a high-priority hygiene issue when multiplied across thousands of daily browsing endpoints.
Why not higher?
This is not a pre-auth server-side RCE and it does not appear to provide code execution, persistence, or a sandbox break on its own. The attack still depends on a user loading crafted content, and the currently visible threat intel does not show active exploitation or turnkey public weaponization.
Why not lower?
Calling this low would ignore the product context: Chrome is ubiquitous and exposed to untrusted content continuously. In a 10,000-host fleet, a user-interaction browser bug with potential sensitive-data disclosure can produce enough aggregate risk to outrank ordinary medium desktop findings.
What to do — in priority order.
- Force auto-update compliance — Ensure Chrome update policies are enforced through enterprise management so endpoints converge on
149.0.7827.53/54or later. For a HIGH verdict, deploy this control within 30 days; sooner if your browser patch channel is already centralized. - Harden web filtering — Block newly registered domains, malvertising categories, and known suspicious redirects at DNS/proxy layers to reduce lure success. This is a practical exposure reducer while patch adoption catches up; for HIGH, put it in place within 30 days.
- Use browser isolation for risky populations — Apply remote browser isolation or equivalent rendering separation for high-risk user groups such as finance, executives, and external-facing staff. It does not fix the flaw, but it can sharply reduce direct exploitability from hostile web content; target deployment within 30 days for the highest-risk cohorts.
- Constrain session value in the browser — Shorten token lifetimes where feasible and prefer phishing-resistant auth plus device-bound sessions so any leaked browser-resident material ages out faster or is less reusable. For a HIGH finding, apply policy-level reductions within 30 days where business impact is acceptable.
- MFA alone does not stop an in-browser confidentiality leak if session material or page-resident data is what's exposed.
- Perimeter firewalls do not materially help because the attack arrives through ordinary outbound web browsing.
- EDR-only reliance is weak here; many info leaks do not produce a crisp host artifact unless they crash or chain into something noisier.
Crowdsourced verification payload.
Run this on the target endpoint or through your software inventory/remote execution tooling. Invoke it with python3 chrome_cve_2026_10992_check.py (Windows example: py chrome_cve_2026_10992_check.py); it needs only normal user read access to the Chrome binary/version metadata.
#!/usr/bin/env python3
# CVE-2026-10992 Chrome version check
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN / Chrome not found / cannot determine
import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path
def parse_version(v):
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', v or '')
if not m:
return None
return tuple(int(x) for x in m.groups())
def cmp_ver(a, b):
return (a > b) - (a < b)
def run_cmd(cmd):
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
out = (p.stdout or '') + '\n' + (p.stderr or '')
return p.returncode, out.strip()
except Exception:
return 99, ''
def find_windows_version():
candidates = [
os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
]
for exe in candidates:
if exe and os.path.exists(exe):
try:
import ctypes
from ctypes import wintypes
GetFileVersionInfoSizeW = ctypes.windll.version.GetFileVersionInfoSizeW
GetFileVersionInfoW = ctypes.windll.version.GetFileVersionInfoW
VerQueryValueW = ctypes.windll.version.VerQueryValueW
size = GetFileVersionInfoSizeW(exe, None)
if not size:
continue
res = ctypes.create_string_buffer(size)
if not GetFileVersionInfoW(exe, 0, size, res):
continue
lptr = ctypes.c_void_p()
lsize = wintypes.UINT()
if not VerQueryValueW(res, '\\', ctypes.byref(lptr), ctypes.byref(lsize)):
continue
class VS_FIXEDFILEINFO(ctypes.Structure):
_fields_ = [
('dwSignature', wintypes.DWORD),
('dwStrucVersion', wintypes.DWORD),
('dwFileVersionMS', wintypes.DWORD),
('dwFileVersionLS', wintypes.DWORD),
('dwProductVersionMS', wintypes.DWORD),
('dwProductVersionLS', wintypes.DWORD),
('dwFileFlagsMask', wintypes.DWORD),
('dwFileFlags', wintypes.DWORD),
('dwFileOS', wintypes.DWORD),
('dwFileType', wintypes.DWORD),
('dwFileSubtype', wintypes.DWORD),
('dwFileDateMS', wintypes.DWORD),
('dwFileDateLS', wintypes.DWORD),
]
ffi = ctypes.cast(lptr.value, ctypes.POINTER(VS_FIXEDFILEINFO)).contents
ms = ffi.dwFileVersionMS
ls = ffi.dwFileVersionLS
version = f'{(ms >> 16) & 0xFFFF}.{ms & 0xFFFF}.{(ls >> 16) & 0xFFFF}.{ls & 0xFFFF}'
return exe, version
except Exception:
rc, out = run_cmd(['powershell', '-NoProfile', '-Command', f"(Get-Item '{exe}').VersionInfo.ProductVersion"])
if rc == 0 and out:
return exe, out.splitlines()[-1].strip()
return None, None
def find_macos_version():
app = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
if os.path.exists(app):
rc, out = run_cmd([app, '--version'])
if rc == 0 and out:
return app, out
return None, None
def find_linux_version():
for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']:
path = shutil.which(name)
if path:
rc, out = run_cmd([path, '--version'])
if rc == 0 and out:
return path, out
candidates = [
'/opt/google/chrome/chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/snap/bin/chromium',
]
for path in candidates:
if os.path.exists(path):
rc, out = run_cmd([path, '--version'])
if rc == 0 and out:
return path, out
return None, None
def main():
system = platform.system().lower()
path = version_str = None
if 'windows' in system:
path, version_str = find_windows_version()
fixed = (149, 0, 7827, 54) # Windows/Mac fixed at 149.0.7827.53/54; treat .54+ as clearly patched
os_label = 'windows'
elif 'darwin' in system:
path, version_str = find_macos_version()
fixed = (149, 0, 7827, 54) # Windows/Mac
os_label = 'macos'
else:
path, version_str = find_linux_version()
fixed = (149, 0, 7827, 53) # Linux
os_label = 'linux'
if not path or not version_str:
print('UNKNOWN - Chrome not found or version could not be determined')
sys.exit(2)
ver = parse_version(version_str)
if not ver:
print(f'UNKNOWN - Found Chrome at {path} but could not parse version from: {version_str}')
sys.exit(2)
if cmp_ver(ver, fixed) < 0:
print(f'VULNERABLE - {os_label} Chrome version {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} is below fixed version {fixed[0]}.{fixed[1]}.{fixed[2]}.{fixed[3]}')
sys.exit(1)
print(f'PATCHED - {os_label} Chrome version {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} meets or exceeds fixed version {fixed[0]}.{fixed[1]}.{fixed[2]}.{fixed[3]}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- Google Chrome Releases - Early Stable Update for Desktop (May 29, 2026)
- Canadian Centre for Cyber Security - Google Chrome security advisory AV26-544
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
- FIRST Exploit Prediction Scoring System overview
- Chromium Security page
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.