Inappropriate implementation in V8 in Google Chrome prior to 149

CVE-2026-10989 is a V8 memory-safety flaw in Google Chrome that affects versions before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. The public description says a remote attacker must get a user onto a crafted HTML page and then convince them to perform *specific UI gestures* before heap corruption is reachable, which is materially narrower than a plain drive-by browser bug.

Google labeled it HIGH at 8.8, and that is fair as a worst-case technical baseline for a browser memory corruption issue. In enterprise reality, though, the chain is narrower: it is client-side, requires user interaction, requires *specific* gestures beyond a click, has no public in-the-wild evidence, no KEV listing, and no public exploit chain showing sandbox escape or reliable post-compromise impact, so the vendor number overstates operational urgency for fleet patch prioritization.

Why this verdict

• Vendor baseline starts at 8.8, but that assumes technical impact in a vacuum; I start there because Chrome is ubiquitous and V8 bugs can be serious.
• UI:R is real downward pressure; the attacker cannot simply hit a listening service, they need a human in the loop on a crafted page.
• The advisory says specific UI gestures, not just a click; that is another explicit friction point, so I subtract again for exploit reach and reliability.
• This is post-content-delivery, not internet-exposed infrastructure; you cannot mass-scan enterprises for it the way you can VPN, edge, or server CVEs.
• No KEV and no public active exploitation mean there is no evidence-backed urgency override.
• No public sandbox-escape chain in the reviewed sources limits confidence in worst-case endpoint compromise from this CVE alone.

Why not higher?

If this were being exploited in the wild, KEV-listed, or described as a straight drive-by renderer RCE with no extra gesture requirement, it would stay in HIGH. Chrome/V8 memory bugs deserve respect, but this record publicly describes a narrower user-driven path and does not show the kind of chaining evidence that justifies emergency fleet disruption.

Why not lower?

This is still a remotely delivered browser memory-corruption issue in a massively deployed product, not harmless noise. If an attacker can reliably steer users into the required interaction path, the potential impact on browser confidentiality, integrity, and availability is meaningful enough that backlog-only treatment would be too relaxed.

1. Enforce auto-update compliance — Make sure Chrome stable-channel auto-update is enabled and that version drift is visible in your endpoint inventory. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but evergreen browser drift should still be corrected in the next normal software-compliance cycle.
2. Reduce untrusted web exposure — Apply or tighten Secure Web Gateway, DNS filtering, browser isolation, and ad/malvertising controls for high-risk user groups. These controls cut off the attacker before the crafted page reaches V8; for MEDIUM, use them as risk reduction while completing patching inside the 365-day remediation window.
3. Hunt for stale Chrome builds — Query your fleet for Chrome versions below 149.0.7827.53 (149.0.7827.54 on some Windows/macOS channels) and focus first on unmanaged endpoints, kiosks, VDI gold images, and systems with disabled updates. The practical problem here is not exposure on the internet; it is update drift on endpoints.
4. Monitor browser crash anomalies — Watch EDR, MDM, or browser telemetry for spikes in Chrome renderer crashes and suspicious child-process behavior after visits to untrusted sites. This does not prevent exploitation, but it is one of the few realistic ways to catch a live attempt in user space.

Run this on the target endpoint or via your EDR/MDM remote execution channel. Invoke it with python3 check_chrome_cve_2026_10989.py on Windows, macOS, or Linux; no admin rights are usually needed if Chrome is installed in standard locations, but broader file-system search works better with local read access.

#!/usr/bin/env python3
# check_chrome_cve_2026_10989.py
# Determine whether local Google Chrome version is vulnerable to CVE-2026-10989.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys
from typing import Optional, Tuple

FIXED_LINUX = (149, 0, 7827, 53)
FIXED_WIN_MAC_MIN = (149, 0, 7827, 53)  # some channels show 53, some 54; 53 is the minimum fixed build family


def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


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 999, ''


def check_binary(path: str) -> Optional[Tuple[int, int, int, int]]:
    if not path or not os.path.exists(path):
        return None
    rc, out = run_cmd([path, '--version'])
    if rc in (0, 1):
        v = parse_version(out)
        if v:
            return v
    return None


def get_version_windows() -> Optional[Tuple[int, int, int, int]]:
    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 c in candidates:
        v = check_binary(c)
        if v:
            return v
    return None


def get_version_macos() -> Optional[Tuple[int, int, int, int]]:
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]
    for c in candidates:
        v = check_binary(c)
        if v:
            return v
    return None


def get_version_linux() -> Optional[Tuple[int, int, int, int]]:
    names = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
    for name in names:
        path = shutil.which(name)
        if path:
            v = check_binary(path)
            if v:
                return v
    return None


def compare(v1, v2):
    return (v1 > v2) - (v1 < v2)


def main():
    system = platform.system().lower()
    version = None
    fixed = FIXED_WIN_MAC_MIN

    if 'windows' in system:
        version = get_version_windows()
        fixed = FIXED_WIN_MAC_MIN
    elif 'darwin' in system or 'mac' in system:
        version = get_version_macos()
        fixed = FIXED_WIN_MAC_MIN
    elif 'linux' in system:
        version = get_version_linux()
        fixed = FIXED_LINUX
    else:
        print('UNKNOWN: unsupported operating system')
        sys.exit(2)

    if not version:
        print('UNKNOWN: Chrome/Chromium version not found')
        sys.exit(2)

    if compare(version, fixed) < 0:
        print(f'VULNERABLE: detected version {".".join(map(str, version))} is below fixed {".".join(map(str, fixed))}')
        sys.exit(1)
    else:
        print(f'PATCHED: detected version {".".join(map(str, version))} is at or above fixed {".".join(map(str, fixed))}')
        sys.exit(0)


if __name__ == '__main__':
    main()

Sources

1. Google Chrome Releases - Stable Channel Update for Desktop
2. NVD - CVE-2026-10989
3. CVE Record - CVE-2026-10989
4. Chromium issue 516311623
5. Canadian Centre for Cyber Security advisory AV26-544
6. CISA Known Exploited Vulnerabilities Catalog
7. VulDB entry for CVE-2026-10989
8. Chromium Security page