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.
4 steps from start to impact.
Land renderer execution with a separate browser exploit
- 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
- 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
Reach the Glic attack surface
- 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
- Feature rollout is gradual, not universal
- Incognito is excluded
- Managed environments can disable Gemini integrations entirely
Trigger the use-after-free in Glic
- Precise control over browser state after renderer compromise
- Reliable trigger sequence for the UAF
- Vulnerable Glic code path is reachable in that build
- Fresh Chrome memory-corruption exploits are reliability-sensitive
- Restricted bug details slow copycat weaponization
- Needs a stable chain, not just a crash
Expand impact beyond the renderer sandbox
- Exploit chain succeeds without crashing the browser
- Target data or capability is reachable from the new context
- 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
- 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.
The supporting signals.
| In-the-wild status | No public evidence found of active exploitation for this specific CVE as of 2026-06-05; not in CISA KEV. |
|---|---|
| PoC availability | No public PoC or exploit repo found for CVE-2026-10990. Bug details remain restricted via Chromium issue handling, which slows opportunistic weaponization. |
| EPSS | 0.00035 from the supplied intel — extremely low likelihood signal relative to actively-abused browser bugs. Percentile was not provided in the supplied intel. |
| KEV status | Not listed in the CISA Known Exploited Vulnerabilities Catalog. |
| Vendor severity mismatch | Your 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 check | Supplied 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 versions | Chrome 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 versions | Upgrade 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 population | Client-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 reporter | Publicly 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. |
Sources.
- Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- Google Chrome Help - Use Gemini in Chrome
- Chrome Enterprise and Education Help - Gemini in Chrome
- Unit 42 - Vulnerability in Chrome Allowed Extensions to Hijack New Gemini Panel
- Canadian Centre for Cyber Security - Google Chrome security advisory (AV26-544)
- GovCERT.HK - Multiple Vulnerabilities in Google Chrome
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
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.
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.
#!/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()