CVE-2026-0628: Chrome WebView Escalation via Gemini Panel
Just caught the latest report on CVE-2026-0628. It’s a high-severity privilege escalation flaw (CVSS 8.8) in Google Chrome stemming from insufficient policy enforcement in the WebView tag. What stands out here is the attack vector: researchers found that malicious extensions could abuse the Gemini Panel interface to bridge the gap between the browser sandbox and the local filesystem.
Essentially, the vulnerability allows a malicious extension to manipulate the WebView policy in a way that bypasses standard security checks. Since the Gemini Panel handles AI interactions, it likely requests specific IPC capabilities or permissions that weren't strictly validated against the extension's origin. By exploiting this, an attacker could potentially read sensitive files on the host system. Google pushed the patch in early January 2026, but legacy environments are always a concern.
For those auditing their fleets, ensure your Chrome instances are updated past the January 2026 patch level. You can verify versions via CLI:
# Linux/ macOS check
google-chrome --version
# Or for Windows environments using PowerShell
Get-ItemProperty 'HKLM:\SOFTWARE\Google\Update\Clients\{8A69D345-D564-463C-AFF1-A69D9E530F96}' -Name pv | Select-Object -ExpandProperty pv
Detection-wise, I'd suggest setting up alerts for Chrome extension processes attempting to access sensitive directories outside of standard user downloads.
The big question here is extension management. With the Chrome Web Store acting as the primary gatekeeper, how do you all handle the risk of 'trojanized' legitimate extensions in your orgs? Are you relying on Google's vetting, or have you moved to a strict allowlist?
Strict allowlists are the only way to sleep at night. We use the ExtensionSettings policy in our Google Workspace admin console to explicitly force-install and block everything else. It’s a bit heavy on the admin side, but it completely neutralizes the 'malicious extension' vector. If it's not on the list, it doesn't load. We caught a similar issue last year with a grammar checking extension trying to inject scripts into banking portals.
From a SOC perspective, we're hunting for this by monitoring for unusual child processes spawned by the Chrome renderer process. If chrome.exe (or the equivalent sandboxed process) is spawning cmd.exe or powershell.exe without user interaction, that's a massive red flag. We added a KQL rule to our Sentinel tenant:
DeviceProcessEvents
| where InitiatingProcessFileName == "chrome.exe"
| where FileName in~ ("cmd.exe", "powershell.exe", "bash")
This reminds me a lot of the issues we saw with Electron apps abusing WebViews a few years back. The Gemini Panel integration essentially turns the browser into a local host, which creates a massive attack surface if the policy enforcement is weak. I'm currently pentesting a client's environment and checking if their internal tools rely heavily on WebViews—if so, this CVE is a critical finding for them.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access