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
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. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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.
- 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.
- 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.
- 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.
- 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.
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()
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.