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

Insufficient data validation in Animation in Google Chrome prior to 149

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

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.

"Low exploit buzz, but this is a web-reachable browser info leak on a massively exposed client fleet."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Deliver a malicious page

The attacker hosts or injects a crafted HTML page that exercises the vulnerable Animation code path. The practical weapon is a custom browser exploit harness in HTML/CSS/JS; no publicly referenced off-the-shelf kit or named PoC is available from the sources reviewed.
Conditions required:
  • Target runs Chrome below 149.0.7827.53 on Linux or below 149.0.7827.53/54 on Windows/macOS
  • Attacker can get the user to load attacker-controlled web content
Where this breaks in practice:
  • 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
Detection/coverage: Network and email controls may see the lure, but vulnerability scanners generally only confirm vulnerable browser version, not exploit attempts.
STEP 02

Trigger the vulnerable Animation path

Once rendered, the page feeds malformed or unexpected data into the Animation component until the insufficient validation condition is hit. Based on the vendor wording and CVSS, the expected outcome is disclosure of data from browser process memory or adjacent state rather than code execution.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: EDR usually will not see a clean signal unless the browser crashes, emits diagnostics, or chains into a second-stage payload.
STEP 03

Exfiltrate disclosed data

If the leak succeeds, the attacker harvests whatever sensitive material becomes exposed to the crafted page or its surrounding execution context. In the absence of a public technical write-up, assume opportunistic disclosure risk — tokens, cross-origin residue, or other process-resident data — rather than guaranteed crown-jewel extraction.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: DLP, proxy logs, browser crash telemetry, and anomaly monitoring on session/token abuse are better bets than signature-based exploit detection.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence of active exploitation found in the reviewed authoritative sources; not listed in CISA KEV.
KEV statusNot present in the CISA Known Exploited Vulnerabilities Catalog as reviewed.
Public PoCNo public GitHub or researcher PoC surfaced in source review. That lowers near-term commoditization pressure.
EPSSUser-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 percentileNot 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 vectorCVSS: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 versionsChrome 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 versionsFixed 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 / reportingGoogle'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 realityShodan/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.
04 · The Call

noisgate verdict.

Final Verdict
UPGRADED to HIGH (7.1/10)

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.

HIGH Affected/fixed version mapping from Google and Cyber Centre advisories
MEDIUM Exploitability assessment without a public technical root-cause write-up
MEDIUM Operational severity upgrade from vendor MEDIUM to noisgate HIGH

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:N matters more here than in niche client software.
  • Downward pressure from required user action: UI:R means 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.

05 · Compensating Control

What to do — in priority order.

  1. Force auto-update compliance — Ensure Chrome update policies are enforced through enterprise management so endpoints converge on 149.0.7827.53/54 or later. For a HIGH verdict, deploy this control within 30 days; sooner if your browser patch channel is already centralized.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: treat this as a browser-fleet priority, not a panic fire. Because I reassessed it as HIGH, apply temporary exposure reduction measures under the noisgate mitigation SLA within 30 days — enforce Chrome auto-update, tighten web filtering, and isolate the highest-risk browsing populations first — then complete the actual Chrome upgrade under the noisgate remediation SLA within 180 days. In practice, most enterprises should finish faster than that because Chrome updates are operationally easy and the exposed population is huge even without active exploitation evidence.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Google Chrome Releases - Early Stable Update for Desktop (May 29, 2026)
  3. Canadian Centre for Cyber Security - Google Chrome security advisory AV26-544
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS API documentation
  6. FIRST Exploit Prediction Scoring System overview
  7. Chromium Security page
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.