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

Use after free in Glic in Google Chrome prior to 149

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

This is a spare key hidden behind three locked doors, not an open front door

CVE-2026-10990 is a use-after-free in Chrome's Glic component — the Gemini-in-Chrome side panel / agent surface — affecting Chrome versions before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. The public description says exploitation requires a remote attacker who has already compromised the renderer process, which makes this a post-renderer-compromise escape or privilege-expansion primitive, not a one-bug drive-by full compromise.

The supplied 9.6/CRITICAL framing overshoots reality for enterprise scheduling. Google itself classed this bug as Medium in the June 2, 2026 Chrome stable advisory, and the real-world friction is the whole story: the attacker must first land renderer code execution, then reach a Glic/Gemini-in-Chrome path that is still being gradually rolled out, requires sign-in, supported region/language, and may be disabled by enterprise policy. That keeps this important, but not emergency-critical on its own.

"This is a useful exploit-chain piece, not a fleet-wide Chrome fire alarm by itself."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land renderer execution with a separate browser exploit

The attacker first needs a separate initial exploit — typically a crafted HTML/JS bug — to gain code execution inside Chrome's sandboxed renderer. CVE-2026-10990 is not that entry vector; it is a follow-on primitive. In practice this means a weaponized chain needs at least one other browser bug or another way to compromise the renderer first.
Conditions required:
  • User visits attacker-controlled or attacker-influenced content
  • Attacker has a working renderer exploit or equivalent renderer compromise path
  • Target is on a vulnerable Chrome build
Where this breaks in practice:
  • Requires a second bug or prior compromise stage before CVE-2026-10990 matters
  • Modern Chrome exploit mitigations make reliable renderer RCE non-trivial
  • No public in-the-wild chain was found for this CVE
Detection/coverage: Web proxies and EDR may catch delivery infrastructure, but there is no scanner that directly proves renderer compromise from the network. Crash telemetry and browser exploit detections help more than vuln scanning here.
STEP 02

Reach the Glic attack surface

The post-compromise payload then has to interact with Glic / Gemini in Chrome, the privileged AI side-panel surface discussed in Google's help and enterprise docs. That matters because Glic is not universally present or usable: Google says the feature is gradually released, requires supported region/language, latest Chrome, signed-in use, and may require admin enablement for work accounts.
Conditions required:
  • Gemini in Chrome/Glic is available on the endpoint
  • User is signed in to Chrome
  • Device/locale/region is eligible
  • Enterprise policy has not disabled Gemini in Chrome
Where this breaks in practice:
  • Feature rollout is gradual, not universal
  • Incognito is excluded
  • Managed environments can disable Gemini integrations entirely
Detection/coverage: Asset inventory can identify Chrome version, but most scanners will not inventory Glic eligibility or policy state. You need browser policy telemetry or endpoint config collection.
STEP 03

Trigger the use-after-free in Glic

With renderer foothold and Glic reachable, the attacker uses a custom follow-on module targeting the use-after-free condition in Glic to cross a boundary or gain stronger execution. The exact bug details remain restricted, which is normal for fresh Chrome fixes, so there is no public exploit recipe to copy straight off GitHub.
Conditions required:
  • Precise control over browser state after renderer compromise
  • Reliable trigger sequence for the UAF
  • Vulnerable Glic code path is reachable in that build
Where this breaks in practice:
  • Fresh Chrome memory-corruption exploits are reliability-sensitive
  • Restricted bug details slow copycat weaponization
  • Needs a stable chain, not just a crash
Detection/coverage: Look for unusual Chrome crashes, repeated renderer restarts, or post-browser anomalous behavior. Signature coverage is likely weak until vendors build detections from real samples.
STEP 04

Expand impact beyond the renderer sandbox

If successful, the attacker turns a sandboxed foothold into a higher-value browser compromise. Prior public research on Chrome's Gemini/Glic surface shows why defenders should care: privileged Gemini panel contexts can expose capabilities the ordinary web renderer should not have. That makes this bug a chain amplifier, not a stand-alone mass exploitation event.
Conditions required:
  • Exploit chain succeeds without crashing the browser
  • Target data or capability is reachable from the new context
Where this breaks in practice:
  • Blast radius stays on the endpoint already being browsed by the victim
  • Still user-context, not instant wormable enterprise takeover
  • Impact depends heavily on what the chained exploit actually achieves
Detection/coverage: EDR is your best shot: unusual Chrome child behavior, access to sensitive files, odd browser process memory activity, and browser policy bypass attempts.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence found of active exploitation for this specific CVE as of 2026-06-05; not in CISA KEV.
PoC availabilityNo public PoC or exploit repo found for CVE-2026-10990. Bug details remain restricted via Chromium issue handling, which slows opportunistic weaponization.
EPSS0.00035 from the supplied intel — extremely low likelihood signal relative to actively-abused browser bugs. Percentile was not provided in the supplied intel.
KEV statusNot listed in the CISA Known Exploited Vulnerabilities Catalog.
Vendor severity mismatchYour supplied intel says CRITICAL 9.6, but Google's June 2, 2026 Chrome release notes label CVE-2026-10990 as Medium. For Chrome bugs, I trust the vendor's exploit-precondition language more than a generic top-line CVSS.
CVSS vector reality checkSupplied vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. The score inflation driver is Scope: Changed + full CIA, but the description's renderer-compromise prerequisite is exactly the kind of real-world friction CVSS underweights.
Affected versionsChrome before 149.0.7827.53; Google's desktop rollout notes specify 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/Mac).
Fixed versionsUpgrade to 149.0.7827.53 or later; on Windows/macOS many fleets will see 149.0.7827.54. There are no distro backports noted in the vendor materials reviewed.
Exposure populationClient-side only — there is no meaningful Shodan/Censys/GreyNoise-style internet-exposed surface to count here. Exposure is your endpoint population running vulnerable Chrome builds with Glic/Gemini in Chrome available and enabled; that is a material narrowing factor.
Disclosure and reporterPublicly disclosed 2026-06-04 in CVE feeds; Google's stable-channel release was 2026-06-02. Google credits Weipeng Jiang (@Krace) of VRI, reported 2026-04-25.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.4/10)

The decisive factor is the attacker position requirement: this bug only becomes useful after the attacker has already compromised Chrome's renderer. That makes CVE-2026-10990 a valuable exploit-chain enhancer but a poor stand-alone predictor of immediate fleet-wide risk.

HIGH The renderer-compromise prerequisite materially lowers stand-alone urgency
MEDIUM Glic/Gemini-in-Chrome rollout and policy state reduce reachable population
MEDIUM Exact post-exploitation impact is partially inferred because bug details remain restricted

Why this verdict

  • Baseline down: Google's own release notes classify CVE-2026-10990 as Medium, not Critical, which is a strong signal the vendor sees meaningful exploitation friction.
  • Major friction — post-initial-access inside the browser: the description says the attacker must have already compromised the renderer process. That implies this is not the first bug in the chain.
  • Reachable population narrows again: the target also needs Glic/Gemini in Chrome available, which Google says is gradually rolled out, requires sign-in, supported region/language, and can be disabled by enterprise policy.
  • No live-fire signals: no KEV listing, no public exploitation evidence found, no public PoC found, and supplied EPSS 0.00035 is minimal.
  • Still not low: Chrome is ubiquitous, the bug sits in a privileged browser-adjacent feature, and a sandbox-escape style primitive remains highly valuable to real exploit developers when paired with another browser bug.

Why not higher?

A higher rating would require either stand-alone exploitation, broadly reachable attack surface, or active exploitation evidence. We have none of those here: the attacker needs renderer compromise first, and the Glic feature itself is not universally reachable across managed fleets.

Why not lower?

This is still memory corruption in a widely deployed browser, not a cosmetic policy bypass. If an attacker already has renderer execution, bugs in privileged Chrome surfaces like Glic can be the difference between a dead-end sandbox and a meaningful endpoint compromise.

05 · Compensating Control

What to do — in priority order.

  1. Patch Chrome through the normal browser ring — Move endpoints to 149.0.7827.53+ (or 149.0.7827.54 where that's the Windows/macOS build) as part of your standard browser update motion. Because the reassessed verdict is MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but in practice browsers should ride your routine fast ring rather than backlog purgatory.
  2. Disable Gemini in Chrome where business use is low — If your fleet does not need Gemini in Chrome, use Chrome Enterprise GeminiSettings / Gemini app controls to turn the feature off and shrink the reachable attack surface. For a MEDIUM verdict there is no mitigation SLA, so treat this as an exposure-reduction option during normal policy maintenance rather than an emergency block.
  3. Prioritize patching on high-risk browsing tiers — Patch admin workstations, researchers, finance, executives, and users who regularly open untrusted web content first. The bug is only valuable after renderer compromise, so the best return comes from systems with the highest probability of seeing hostile content.
  4. Harden extension and browser policy hygiene — Keep Chrome signed-in policy, extension allowlisting, and browser management intact so Glic/Gemini rollout state remains visible and controllable. This does not fix CVE-2026-10990, but it reduces adjacent browser-chain options and improves scoping.
What doesn't work
  • A network IDS signature will not solve this; the vulnerable surface is a client-side browser feature and the critical prerequisite is post-renderer compromise, not a single stable network IOC.
  • Perimeter exposure scanning does not help much; there is no internet-facing server surface to count the way you would with VPNs, firewalls, or appliances.
  • A generic WAF is mostly irrelevant because exploitation is delivered through browser behavior on the endpoint, not by protecting a server you own.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your EDR/live-response tool. Invoke it with python3 check_chrome_cve_2026_10990.py; it needs only standard user rights and reports VULNERABLE, PATCHED, or UNKNOWN based on the locally installed Google Chrome version.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check Google Chrome version for CVE-2026-10990 exposure
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys

THRESHOLD = (149, 0, 7827, 53)


def parse_version(text):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text or '')
    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 out.strip()
    except Exception:
        return ''


def get_windows_version():
    cmds = [
        ['reg', 'query', r'HKLM\Software\Google\Chrome\BLBeacon', '/v', 'version'],
        ['reg', 'query', r'HKCU\Software\Google\Chrome\BLBeacon', '/v', 'version'],
        ['powershell', '-NoProfile', '-Command', "(Get-Item 'C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe').VersionInfo.ProductVersion"],
        ['powershell', '-NoProfile', '-Command', "(Get-Item 'C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe').VersionInfo.ProductVersion"]
    ]
    for cmd in cmds:
        out = run_cmd(cmd)
        ver = parse_version(out)
        if ver:
            return ver
    return None


def get_macos_version():
    chrome_bin = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
    if os.path.exists(chrome_bin):
        out = run_cmd([chrome_bin, '--version'])
        ver = parse_version(out)
        if ver:
            return ver
    return None


def get_linux_version():
    candidates = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
    for name in candidates:
        path = shutil.which(name)
        if path:
            out = run_cmd([path, '--version'])
            ver = parse_version(out)
            if ver:
                return ver
    return None


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

    if 'windows' in system:
        version = get_windows_version()
    elif 'darwin' in system:
        version = get_macos_version()
    elif 'linux' in system:
        version = get_linux_version()

    if not version:
        print('UNKNOWN: Could not determine installed Google Chrome version')
        sys.exit(2)

    version_str = '.'.join(str(x) for x in version)
    threshold_str = '.'.join(str(x) for x in THRESHOLD)

    if version < THRESHOLD:
        print(f'VULNERABLE: Installed Chrome version {version_str} is older than {threshold_str}')
        sys.exit(1)
    else:
        print(f'PATCHED: Installed Chrome version {version_str} is at or above {threshold_str}')
        sys.exit(0)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not treat this like a drop-everything browser zero-day unless you also have evidence of renderer exploitation in your environment. Use endpoint inventory to find Chrome builds older than 149.0.7827.53, patch them through your normal browser channel, and optionally disable Gemini in Chrome where it is not needed. For a MEDIUM reassessment there is no noisgate mitigation SLA — go straight to the 365-day remediation window; the noisgate remediation SLA is therefore ≤ 365 days, though most teams should finish this in the next routine Chrome wave rather than letting it age.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Google Chrome Help - Use Gemini in Chrome
  3. Chrome Enterprise and Education Help - Gemini in Chrome
  4. Unit 42 - Vulnerability in Chrome Allowed Extensions to Hijack New Gemini Panel
  5. Canadian Centre for Cyber Security - Google Chrome security advisory (AV26-544)
  6. GovCERT.HK - Multiple Vulnerabilities in Google Chrome
  7. CISA Known Exploited Vulnerabilities Catalog
  8. FIRST EPSS API documentation
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.