A low-privilege Chrome extension could hijack Google’s Gemini AI panel, inheriting its access to your camera, microphone, local files, and screenshots. CVE-2026-0628, dubbed “GlicJack” by Palo Alto Networks’ Unit 42, is a CVSS 8.8 vulnerability that reveals a fundamental tension in browser-embedded AI: the more powerful the assistant, the bigger the target.
What Happened
Chrome’s “Gemini Live in Chrome” feature embeds gemini.google.com/app inside a privileged WebView component at chrome://glic. Unlike a normal web page, this panel has elevated permissions — it can access your camera, microphone, take screenshots of any tab, and read local files.
The vulnerability was in Chrome’s declarativeNetRequest (DNR) handling. Chrome failed to exclude the chrome://glic WebView from extension DNR rules. Any extension with basic network-filtering permissions could intercept and modify HTTPS traffic to gemini.google.com/app when loaded inside the Gemini panel.
The attack chain:
- User installs a seemingly benign Chrome extension with DNR permissions
- Extension intercepts traffic to
gemini.google.com/appinside the Gemini panel - Extension injects JavaScript into the privileged Gemini side panel
- Attacker-controlled code now runs with full Gemini panel privileges
What the Attacker Could Do
Once inside the Gemini panel, the attacker’s code inherited all of its permissions:
- Start camera and microphone without new user consent
- Access local files and directories on the underlying OS
- Take screenshots of any HTTPS site the user is viewing
- Display phishing content inside the trusted Gemini side panel UI
This bypasses Chrome’s extension isolation model entirely. An extension that should only be able to filter network requests becomes a full-privilege “driver” for the AI assistant.
Why This Matters Beyond Chrome
GlicJack is the latest in a pattern. Every major browser vendor is racing to embed AI assistants as privileged first-party components:
- Chrome has Gemini Live in the side panel
- Edge has Copilot with deep page-context access
- Arc had agent-style features before being discontinued
- Opera has Aria with cross-tab awareness
Each of these AI panels operates with more permissions than any normal web page or extension. They need broad access to be useful — reading page content, understanding context, interacting with files. But that same breadth makes them high-value escalation targets.
The PleaseFix vulnerabilities in agentic browsers (which we covered previously) showed that untrusted content could hijack AI browser agents through calendar invites. GlicJack shows the threat also comes from the extension ecosystem — the very extensions users install to enhance their browsing.
The Architectural Problem
Traditional browser security draws clear boundaries: extensions can’t access chrome:// pages, content scripts are sandboxed, permissions are scoped. But AI assistants blur these boundaries by design. They need to:
- Read page content across all tabs (for context)
- Access local files (for document understanding)
- Control camera/microphone (for multimodal interaction)
- Execute actions on the user’s behalf (for agentic workflows)
Every one of these capabilities is something the security model was designed to restrict. AI integration requires poking holes in the sandbox, and each hole is an opportunity.
Timeline
| Date | Event |
|---|---|
| Late 2025 | Gal Weizman (Unit 42) discovers the vulnerability |
| Late 2025 | Reported to Google |
| Jan 2026 | Patched in Chrome 143.0.7499.192/.193 |
| Mar 2026 | Public disclosure with technical details |
What to Do
If you use Chrome with Gemini:
- Update to Chrome 143.0.7499.192 or later (this should have happened automatically)
- Review installed extensions — especially those using declarativeNetRequest permissions
- Remove extensions you don’t actively use
- Enterprise admins: consider extension allowlisting
If you’re building browser-based AI features:
- Privileged AI components need explicit isolation from extension APIs
- DNR, content scripts, and WebRequest APIs should not be able to reach AI panel WebViews
- Audit every path from lower-privilege contexts to your AI component
How OpenClaw Avoids This Class of Bug
OpenClaw’s architecture sidesteps browser-embedded AI vulnerabilities by design:
- No browser panel: OpenClaw runs as a local service, not inside Chrome’s privileged UI
- No extension dependency: Communication happens over local APIs, not through browser extension mechanisms
- Model-agnostic: If Gemini has a browser-specific vulnerability, OpenClaw users can route to a different model without changing their setup
- Explicit permissions: Tool access is configured in
clawdbot.json, not inherited from a browser’s ambient permissions
This doesn’t mean OpenClaw is immune to security issues — it has its own. But it avoids the specific architectural pattern where a browser extension can escalate to AI-assistant-level privileges.
The Bigger Picture
GlicJack, PleaseFix, the MCP SSRF crisis — the security story of early 2026 is clear: AI agents are the new privilege escalation target. Whether they’re embedded in browsers, connected via MCP servers, or running as autonomous agents, every AI system that operates with broad permissions becomes an attractive target for attackers.
The race to embed AI everywhere is moving faster than the security architecture can adapt. Chrome patched this specific bug, but the fundamental tension — useful AI needs broad access, broad access creates attack surface — isn’t going away.
Browser vendors need to treat AI integration as a first-class security boundary, not just another WebView to sandbox. Until they do, expect more GlicJacks.