Insufficient validation of untrusted input in DevTools in Google Chrome prior to 149

CVE-2026-10916 is an *improper input validation* bug in Chrome DevTools affecting Chrome versions prior to 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS. Google lists it as a High-severity DevTools issue reported internally on 2026-03-30 and disclosed in the June 2, 2026 stable release notes; the CVE record was published on 2026-06-04. The public description is incomplete in the advisory snippet you provided, but the wording pattern and neighboring Chrome CVEs strongly indicate this is a *post-renderer-compromise* bug rather than a clean one-click initial access flaw.

paragraph 2: Google calling it High at the Chromium severity layer is understandable from a bug-bar perspective, but operationally this is not Chrome's equivalent of an internet-facing RCE. The decisive friction is the prerequisite: the attacker already needs a compromised renderer process, which means they have already won a separate browser bug or exploit stage. That turns this from a fleet-wide emergency into a *chain-hardening* issue—real, worth patching, but not on the same shelf as unauthenticated renderer RCE or known-exploited sandbox escapes.

Why this verdict

• Requires prior compromise: the public wording indicates an attacker already needs a compromised renderer process, which implies a separate exploit stage landed first.
• Client-side, not edge-exposed: this is not a remotely reachable service on your perimeter; reachable population is every vulnerable browser, but exploitability is gated by browser exploitation conditions and user activity.
• No exploitation heat: no KEV listing, no public PoC, and the supplied EPSS is extremely low, all of which push this down from panic territory.
• Ubiquity keeps it above LOW: Chrome is everywhere in enterprise fleets, and browser-chain bugs matter disproportionately on developer, admin, and privileged workstation populations.

Why not higher?

This does not look like a stand-alone, unauthenticated one-click RCE that an attacker can spray at scale and immediately monetize. The need for a prior renderer compromise is compounding friction: it assumes a separate exploit, reduces opportunistic attacker coverage, and narrows real-world abuse to higher-capability actors or chained attacks.

Why not lower?

Chrome is a universally deployed client and DevTools sits inside a high-value trust boundary. Even post-compromise browser bugs deserve attention because they can turn a contained renderer foothold into a more dangerous chain stage against users with sensitive sessions, privileged access, or developer workflows.

1. Prioritize privileged browsing tiers — Push the fixed Chrome build first to administrators, developers, executives, help-desk staff, and anyone who uses high-value SaaS sessions. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but these user groups should still move earlier because chained browser exploitation pays off most on privileged endpoints.
2. Enforce rapid browser auto-update — Make sure Chrome enterprise policies are not delaying stable-channel uptake more than necessary, and verify restart enforcement where your org uses deferred restarts. There is no mitigation SLA for MEDIUM, so this is about shrinking exposure through normal remediation rather than standing up emergency controls.
3. Harden high-risk browsing paths — Route unknown browsing, research, and threat-intel work through isolated browser profiles, VDI, or remote browser isolation if you already have it. This does not replace patching, but it reduces the value of a renderer-first exploit chain while you work through the remediation window.
4. Tune EDR for browser-child anomalies — Hunt for suspicious behavior where chrome.exe or google-chrome spawns unusual child processes, touches credential stores, or launches scripting engines. Again, no mitigation SLA applies here for MEDIUM; this is a detection-and-containment backstop while standard patch rollout completes.

Run this on the target endpoint or through your endpoint management tooling. Invoke it with python3 check_chrome_cve_2026_10916.py on Linux/macOS or py check_chrome_cve_2026_10916.py on Windows; no admin rights are usually required, but local software inventory access is needed.

#!/usr/bin/env python3
# Check Google Chrome version for CVE-2026-10916
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys

WIN_FIXED = (149, 0, 7827, 53)  # accept 53 or higher; release notes mention 53/54
LINUX_FIXED = (149, 0, 7827, 53)
MAC_FIXED = (149, 0, 7827, 53)  # accept 53 or higher; release notes mention 53/54


def parse_version(text):
    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 '') + ' ' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def find_version_windows():
    candidates = [
        r'C:\Program Files\Google\Chrome\Application\chrome.exe',
        r'C:\Program Files (x86)\Google\Chrome\Application\chrome.exe',
        os.path.expandvars(r'%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe'),
    ]
    for path in candidates:
        if path and os.path.exists(path):
            out = run_cmd([path, '--version'])
            ver = parse_version(out)
            if ver:
                return ver, path
    return None, None


def find_version_linux():
    candidates = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
    for cmd in candidates:
        out = run_cmd([cmd, '--version'])
        ver = parse_version(out)
        if ver:
            return ver, cmd
    return None, None


def find_version_mac():
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]
    for path in candidates:
        if os.path.exists(path):
            out = run_cmd([path, '--version'])
            ver = parse_version(out)
            if ver:
                return ver, path
    return None, None


def compare(ver, fixed):
    if ver is None:
        return None
    if ver < fixed:
        return 'VULNERABLE'
    return 'PATCHED'


def main():
    system = platform.system().lower()
    ver = None
    source = None
    fixed = None

    if 'windows' in system:
        ver, source = find_version_windows()
        fixed = WIN_FIXED
    elif 'linux' in system:
        ver, source = find_version_linux()
        fixed = LINUX_FIXED
    elif 'darwin' in system or 'mac' in system:
        ver, source = find_version_mac()
        fixed = MAC_FIXED
    else:
        print('UNKNOWN - unsupported platform')
        sys.exit(2)

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

    status = compare(ver, fixed)
    if status == 'VULNERABLE':
        print(f'VULNERABLE - detected {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} from {source}; fixed is {fixed[0]}.{fixed[1]}.{fixed[2]}.{fixed[3]} or later')
        sys.exit(1)
    elif status == 'PATCHED':
        print(f'PATCHED - detected {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]} from {source}')
        sys.exit(0)
    else:
        print('UNKNOWN - comparison failed')
        sys.exit(2)


if __name__ == '__main__':
    main()

Sources

1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
2. Google Chrome Releases archive showing CVE-2026-10916 entry
3. Canadian Centre for Cyber Security advisory AV26-544
4. Chromium Security page
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS
7. GreyNoise CVE enrichment API reference
8. Censys Search product overview