A misleading label on the Gemini side panel — the browser equivalent of a phishing lure with extra steps
This is an *inappropriate implementation* bug (CWE-451, UI misrepresentation) inside Glic, the Chromium component that hosts the Gemini AI side panel. A remote attacker who convinces a user to perform a specific interaction sequence can render the Glic surface in a way that misleads the user about the origin, trust boundary, or content of what they're seeing. Affected versions are all Chrome stable builds prior to 150.0.7871.47. There is no memory corruption, no sandbox escape, no arbitrary code execution — the impact is confined to a UI spoofing / information-disclosure primitive that the attacker still has to socially engineer around.
Vendor severity of MEDIUM (5.3) with vector AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N is honest — arguably slightly generous. The C:H rating assumes the spoof reliably exfiltrates something sensitive (e.g., tricks a user into pasting secrets into a fake-looking Gemini prompt), but AC:H + UI:R means the attacker needs both a specific victim behavior AND a low-reliability trigger. Real-world exploitability against a fleet is closer to LOW.
4 steps from start to impact.
Attacker hosts a crafted web page
- Attacker-controlled origin reachable by the victim
- Chrome < 150.0.7871.47 with Glic/Gemini side panel enabled
- Glic is not enabled by default on all channels/regions
- Enterprise policy
GenAiDefaultSettingsdisables the feature entirely
Victim is lured to the page and interacts
- User clicks through to the malicious page
- User opens or interacts with Glic panel while on the page
- Requires a convinced, engaged user — not drive-by
- Safe Browsing blocks many of the delivery domains attackers would use
- Users on managed profiles often have Glic disabled
Glic renders misleading content
- Trigger reliably fires in the victim's Chrome build
- AC:H — trigger is fragile and version-dependent
- Users increasingly ignore AI panel output; social-engineering yield is modest
Social engineering to information disclosure
- User trusts the spoofed Glic content and acts on it
- Requires a plausible pretext AND a valuable secret AND user compliance
- MFA, DLP, and clipboard-monitoring EDR blunt the yield
ChromeCleanupEnabled + RelaunchNotification=Required via GPO/MDM with a 7-day relaunch deadline — well inside the noisgate 365-day remediation window for a LOW verdict.GenAiDefaultSettings=1 (Do not allow) via Chrome Enterprise policy. Eliminates the attack surface entirely on managed endpoints. No mitigation SLA at LOW — treat as backlog hygiene, deploy on next policy cycle.SafeBrowsingProtectionLevel=2 via policy.- Network IDS/IPS signatures — the bug fires client-side in the renderer; nothing hits the wire that a signature can key on.
- EDR process monitoring — a UI misrender does not spawn processes, drop files, or touch the registry.
- Blocking specific domains — the trigger is a technique, not a payload URL; blocklists chase shadows.
- WAF / email gateway — the bug is triggered by any attacker-controlled page the user visits; email filtering only affects one delivery vector.
The supporting signals.
| In-the-wild exploitation | None reported. Not on CISA KEV. No Google TAG or Mandiant campaign attribution as of 2026-07-01. |
|---|---|
| Public PoC | None public. No GitHub repo, no Metasploit module, no writeup on chromium-review.googlesource.com beyond the sealed bug entry. |
| EPSS | Unpublished at disclosure; historical cohort for Chrome MEDIUM UI-spoof bugs (CWE-451) sits around 0.05–0.15% / <30th percentile. |
| KEV status | Not listed (2026-07-01). |
| CVSS vector | AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N — network-reachable but AC:H + UI:R are the load-bearing downgrades. No integrity/availability impact. |
| Affected versions | All Chrome stable < 150.0.7871.47; Chromium-derived browsers (Edge, Brave, Opera, Vivaldi, Arc) inherit until their upstream merge. |
| Fixed versions | Chrome Stable 150.0.7871.47 (Win/Mac/Linux). Edge/Brave/Opera pending downstream roll — track vendor changelogs. |
| Exposure / footprint | Chrome desktop install base ~3B; Glic/Gemini side panel is gated by region + feature flag + policy — realistically <40% of installs are reachable, most of which will auto-update within 7 days. |
| Disclosure | 2026-06-30 via Chrome Stable channel release notes. |
| Reporter | External researcher credited in Chrome release notes (specific attribution redacted pending broad rollout). |
Sources.
- Chrome Releases blog (Stable channel updates)
- Chrome Enterprise policy list — GenAiDefaultSettings
- CWE-451: User Interface (UI) Misrepresentation of Critical Information
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS model documentation
- Chromium bug tracker (public entries)
- Bleeping Computer — Chrome zero-day coverage
- The Hacker News — Chrome Gemini panel vulnerability
Why this verdict
- No code execution path. CWE-451 spoofing bugs cap out at social-engineering uplift; there is no memory corruption, type confusion, or sandbox weakness described.
- AC:H + UI:R stacked. The attacker needs a fragile trigger AND a cooperative user AND a valuable secret to paste. Real yield against a hardened workforce is minimal.
- Narrow reachable population. Glic is region- and policy-gated; enterprise fleets with
GenAiDefaultSettings=Disabledare not exposed at all. - Chrome auto-update dominates. The typical enterprise Chrome fleet reaches >90% patched within 7 days without any admin action — the mitigation window is largely self-closing.
- Role multiplier: workstation. Chrome runs on user endpoints, not identity/hypervisor/CI infrastructure. There is no fleet-scale blast radius from a browser UI spoof — the deployment-role floor stays at LOW/MEDIUM.
- Not on KEV, no public PoC, no exploitation reports as of assessment date.
Why not higher?
MEDIUM would be defensible if there were a credible PoC combining the Glic spoof with a follow-on primitive (e.g., prompt-injection to Gemini's authenticated context). Absent that chain, the vector's C:H claim is theoretical — the bug is a phishing accessory, not a browser compromise. Nothing here justifies HIGH.
Why not lower?
IGNORE is wrong because the CVE is real, the affected code ships enabled to many users, and CWE-451 has been chained into credential-theft campaigns before. It deserves a tracked patch — just not a fire drill.
Crowdsourced verification payload.
Run on any Windows workstation to check the installed Chrome version against the fix. Invoke from an admin or user PowerShell prompt: .\Check-CVE-2026-14153.ps1. No elevation required; reads registry only.
#Requires -Version 5.0
# Check-CVE-2026-14153.ps1
# Reports VULNERABLE / PATCHED / UNKNOWN for Chrome Glic UI-spoof bug
# Fixed in Chrome 150.0.7871.47
$ErrorActionPreference = 'Stop'
$FixedVersion = [Version]'150.0.7871.47'
function Get-ChromeVersion {
$paths = @(
'HKLM:\SOFTWARE\Google\Update\Clients\{8A69D345-D564-463C-AFF1-A69D9E530F96}',
'HKLM:\SOFTWARE\WOW6432Node\Google\Update\Clients\{8A69D345-D564-463C-AFF1-A69D9E530F96}',
'HKCU:\SOFTWARE\Google\Update\Clients\{8A69D345-D564-463C-AFF1-A69D9E530F96}'
)
foreach ($p in $paths) {
try {
$v = (Get-ItemProperty -Path $p -ErrorAction Stop).pv
if ($v) { return [Version]$v }
} catch {}
}
# Fallback: binary FileVersion
$exe = @(
"$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
"${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe",
"$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe"
) | Where-Object { Test-Path $_ } | Select-Object -First 1
if ($exe) {
return [Version]((Get-Item $exe).VersionInfo.ProductVersion)
}
return $null
}
$installed = Get-ChromeVersion
if (-not $installed) {
Write-Output 'UNKNOWN - Chrome not detected'
exit 2
}
if ($installed -lt $FixedVersion) {
Write-Output ("VULNERABLE - Chrome {0} < {1}" -f $installed, $FixedVersion)
exit 1
} else {
Write-Output ("PATCHED - Chrome {0} >= {1}" -f $installed, $FixedVersion)
exit 0
}