A Chrome Extension Can ‘Read’ Your AI Agent’s Screen With Zero Permissions — Here’s the 2026 Browser Trap That Makes ‘Secure’ Tools Leak Anyway
“Zero permissions” often just means “no scary install banner,” not “no capability.” In 2026, extensions plus AI side panels turn what you’re viewing into a high-value, easily exfiltrated asset—and isolation seams can make it worse.
By TheMurrow Editorial
May 15, 2026
Key Points
- 1Assume any extension you click can read the active tab’s DOM—even “zero-permission” tools—then transmit that text over the network.
- 2Watch the 2026 “browser trap”: AI side panels become trusted, privileged surfaces, making isolation flaws (like CVE-2026-0628) high-impact.
- 3Treat extensions like vendors: limit host access, scrutinize remote UI/iframes, and monitor for DOM extraction plus outbound exfiltration behavior.
The icon under your address bar looks harmless: an AI assistant, a “reader,” a quick summarizer. It promises convenience without the drama—sometimes even boasting “zero permissions,” as if that phrase were a seatbelt.
Then you click it on a Gmail tab, or a finance portal, or an internal dashboard. The extension wakes up, reads what’s on the page, and ships the text elsewhere. No flashing warning. No scary prompt beyond what you already accepted weeks ago.
Chrome’s extension system was built for this kind of power. The surprise is how easily that power can be misread—by users, by reviewers, and sometimes by the people building new “agentic” browser features that can see and act on your behalf. In 2026, the browser itself is becoming a privileged workspace, and the boundary between “helpful” and “high-risk” is thinner than most people think.
Permission prompts describe scope, not outcomes.
— — TheMurrow Editorial
The myth of “zero-permissions”: what Chrome extensions can do by design
A Chrome extension does not need a long list of permissions to be consequential. “Zero permissions” often means “no broad, always-on access”—not “no capability.” Even without requesting sensitive permissions, an extension can still run its own code in the background (via a service worker) and display its own interface through a popup, side panel, new tab, or extension page.
The more important detail is how many extensions rely on user-gesture-gated access rather than persistent access. A common pattern uses `activeTab`, a mechanism that grants temporary access to the current page when the user clicks the extension. Many developers describe this as “minimal permissions,” and it often reduces the severity of warning banners users see during installation.
That design has a legitimate purpose: it limits the extension’s reach to the moment you explicitly invoke it. Yet it also creates a social trap. Users interpret a calm permission screen as “safe,” even when the extension—once clicked—can read what’s in the page’s DOM, extract text, and send it out over the network.
The more important detail is how many extensions rely on user-gesture-gated access rather than persistent access. A common pattern uses `activeTab`, a mechanism that grants temporary access to the current page when the user clicks the extension. Many developers describe this as “minimal permissions,” and it often reduces the severity of warning banners users see during installation.
That design has a legitimate purpose: it limits the extension’s reach to the moment you explicitly invoke it. Yet it also creates a social trap. Users interpret a calm permission screen as “safe,” even when the extension—once clicked—can read what’s in the page’s DOM, extract text, and send it out over the network.
Scope isn’t the same as safety
Chrome’s prompts largely communicate scope: whether an extension can run on all sites, specific sites, or only on the active tab. Prompts rarely communicate outcomes: what an extension might do with what it can read once invoked.
A narrowly permissioned extension can still be dangerous if:
- The user routinely clicks it on sensitive pages (email, HR systems, dashboards).
- The extension can read DOM text (often enough to capture content, tokens, or drafts).
- The extension has any network path to transmit data (direct requests or embedded remote content in its UI).
None of that requires an extension to ask for “Read and change all your data on all websites.” The “minimal” label can be accurate in a technical sense while still misleading in a practical one.
A narrowly permissioned extension can still be dangerous if:
- The user routinely clicks it on sensitive pages (email, HR systems, dashboards).
- The extension can read DOM text (often enough to capture content, tokens, or drafts).
- The extension has any network path to transmit data (direct requests or embedded remote content in its UI).
None of that requires an extension to ask for “Read and change all your data on all websites.” The “minimal” label can be accurate in a technical sense while still misleading in a practical one.
A permission screen can be narrow and still describe a very wide set of harms.
— — TheMurrow Editorial
The 2026 browser trap: AI assistants turn “what’s on your screen” into a privileged asset
AI-assisted browsers and embedded agents shift the security equation because they elevate a new resource: the user’s screen—or, more precisely, what the user is viewing and doing inside the browser. Side panels and assistants are designed to summarize, draft, search, and act across tabs. They need access to context to be useful.
That’s where the trap forms. When agentic features are implemented as (or include) web content—panels, WebViews, embedded UIs—the old separation between:
- normal web pages,
- extension code,
- and privileged browser UI
can blur. Any isolation flaw can become a path for a “low-privilege” extension to influence a privileged surface that has broader capabilities.
Security teams have warned about this pattern for years in different forms, but AI assistants raise the stakes: they centralize sensitive context (messages, tabs, files, voice, screenshots) behind interfaces users instinctively trust because they “belong to the browser.”
That’s where the trap forms. When agentic features are implemented as (or include) web content—panels, WebViews, embedded UIs—the old separation between:
- normal web pages,
- extension code,
- and privileged browser UI
can blur. Any isolation flaw can become a path for a “low-privilege” extension to influence a privileged surface that has broader capabilities.
Security teams have warned about this pattern for years in different forms, but AI assistants raise the stakes: they centralize sensitive context (messages, tabs, files, voice, screenshots) behind interfaces users instinctively trust because they “belong to the browser.”
Privilege escalation by UI proximity
The classic risk with browser extensions is overbroad access. The emerging risk is proximity to privileged agent surfaces—places where the browser itself is permitted to see more, do more, and ask fewer questions of the user because it is “the assistant.”
That does not mean every AI panel is insecure. It means attackers will keep probing the seams between extension land and assistant land—because the payoff is unusually high.
That does not mean every AI panel is insecure. It means attackers will keep probing the seams between extension land and assistant land—because the payoff is unusually high.
Case study: CVE-2026-0628 and the Gemini “Live in Chrome” side panel
A concrete example arrived with the vulnerability tracked as CVE-2026-0628, tied to Chrome’s Gemini “Live in Chrome” panel. Palo Alto Networks’ Unit 42 published details on March 2, 2026, describing a high-severity issue where a malicious extension with basic permissions could inject code into the Gemini panel and effectively inherit the panel’s elevated capabilities.
Unit 42’s write-up matters because it illustrates the mechanism of the “browser trap”: a seemingly modest extension becomes dangerous when it can reach into a privileged assistant surface.
According to Unit 42, the described attack flow could enable actions such as:
- accessing the camera/microphone without consent prompts (in that flow),
- taking screenshots of websites,
- accessing local files/directories,
- and hijacking the panel for phishing by exploiting the trust users place in browser-embedded assistant UI.
Google released a fix in early January 2026, before Unit 42 published the research. That timeline is important: the point is not that Chrome “left it open,” but that this category of flaw is plausible enough to emerge in a marquee, security-resourced product area.
Unit 42’s write-up matters because it illustrates the mechanism of the “browser trap”: a seemingly modest extension becomes dangerous when it can reach into a privileged assistant surface.
According to Unit 42, the described attack flow could enable actions such as:
- accessing the camera/microphone without consent prompts (in that flow),
- taking screenshots of websites,
- accessing local files/directories,
- and hijacking the panel for phishing by exploiting the trust users place in browser-embedded assistant UI.
Google released a fix in early January 2026, before Unit 42 published the research. That timeline is important: the point is not that Chrome “left it open,” but that this category of flaw is plausible enough to emerge in a marquee, security-resourced product area.
When the assistant becomes a trusted surface, hijacking it becomes a shortcut to user trust.
— — TheMurrow Editorial
What to take from the Gemini panel vulnerability
Several secondary write-ups have offered interpretations of the mechanism and affected versions. Unit 42 and official advisories should be treated as primary sources; everything else is commentary. Still, the larger lesson holds without embellishment: agentic browser features expand the number of privileged surfaces worth attacking, and extensions are a natural delivery vehicle.
Security teams should read CVE-2026-0628 as a blueprint for future research. Product teams should read it as a reminder that UI containment and privilege boundaries need to be explicit, not assumed.
Security teams should read CVE-2026-0628 as a blueprint for future research. Product teams should read it as a reminder that UI containment and privilege boundaries need to be explicit, not assumed.
CVE-2026-0628
A high-severity flaw Unit 42 said let a basic-permission extension inject into Gemini’s “Live in Chrome” panel and inherit elevated capabilities.
March 2, 2026
Unit 42’s publication date for the Gemini panel research—after Google had already shipped a fix in early January 2026.
“Read your screen” often means “read your DOM”—and that’s usually enough
When people hear “screen reading,” they imagine pixel capture: screenshots, OCR, video. Many malicious extension campaigns don’t need any of that. They can extract the actual text users care about directly from the page structure—the DOM—using standard JavaScript methods.
From a privacy standpoint, DOM extraction is often equivalent to screen capture. Your inbox, draft emails, internal tickets, and web-based admin consoles are mostly text—and often plainly accessible once a script is allowed to run on the page.
From a privacy standpoint, DOM extraction is often equivalent to screen capture. Your inbox, draft emails, internal tickets, and web-based admin consoles are mostly text—and often plainly accessible once a script is allowed to run on the page.
Why DOM access is the modern skeleton key
DOM access can expose:
- email contents visible in the browser,
- draft text in compose windows,
- on-page account information and identifiers,
- internal knowledge base articles and dashboards.
A key nuance for readers: an extension doesn’t need to “hack” Gmail to read what you’re reading. If you grant it the ability to run on that page—even temporarily with a click—it can often extract content the same way a legitimate “summarize this” tool would.
That’s why permission models focused on where code can run can struggle to communicate what data is at risk. The “what” is whatever you can see and type.
- email contents visible in the browser,
- draft text in compose windows,
- on-page account information and identifiers,
- internal knowledge base articles and dashboards.
A key nuance for readers: an extension doesn’t need to “hack” Gmail to read what you’re reading. If you grant it the ability to run on that page—even temporarily with a click—it can often extract content the same way a legitimate “summarize this” tool would.
That’s why permission models focused on where code can run can struggle to communicate what data is at risk. The “what” is whatever you can see and type.
Key Insight
If an extension can run on a page—even briefly via `activeTab`—assume it can read everything you can see and type there.
Case study: the 2026 AI-themed malicious extension campaign targeting Gmail
The most sobering evidence for this story is not theoretical. It’s operational.
In February 2026, reporting described a campaign of 30+ malicious Chrome extensions disguised as AI chatbots and productivity tools. The Register reported “at least 260,000” installs, while other coverage cited even higher totals. Regardless of the exact number, the scale was large enough to be meaningful: hundreds of thousands of users potentially ran browser code designed to siphon sensitive content.
According to the reporting, the extensions stole data including API keys, email messages, and personal data, and multiple extensions targeted Gmail specifically.
The tactics were not subtle in retrospect. The campaign reportedly used content scripts to extract readable page content—citing use of Mozilla Readability—and, for Gmail, read visible email content from the DOM via mechanisms like `textContent`, including draft/compose text.
In February 2026, reporting described a campaign of 30+ malicious Chrome extensions disguised as AI chatbots and productivity tools. The Register reported “at least 260,000” installs, while other coverage cited even higher totals. Regardless of the exact number, the scale was large enough to be meaningful: hundreds of thousands of users potentially ran browser code designed to siphon sensitive content.
According to the reporting, the extensions stole data including API keys, email messages, and personal data, and multiple extensions targeted Gmail specifically.
The tactics were not subtle in retrospect. The campaign reportedly used content scripts to extract readable page content—citing use of Mozilla Readability—and, for Gmail, read visible email content from the DOM via mechanisms like `textContent`, including draft/compose text.
The remote-iframe problem: behavior that changes without a store update
One tactic stands out because it addresses a common user assumption: “If Google reviews updates, I’m safe.” Several reports noted the use of remote iframe/UI content that could change behavior without requiring an extension update in the store.
That doesn’t mean every extension that loads remote content is malicious. Many legitimate extensions do. The problem is governance: remote content can become a control channel, allowing operators to swap benign UI for data collection or credential theft after the extension has earned distribution and trust.
Google confirmed the extensions were removed from the Chrome Web Store by Feb. 17, 2026, according to The Register’s reporting. Removal helps, but it doesn’t undo exposure for users who installed and used the tools while they were live.
That doesn’t mean every extension that loads remote content is malicious. Many legitimate extensions do. The problem is governance: remote content can become a control channel, allowing operators to swap benign UI for data collection or credential theft after the extension has earned distribution and trust.
Google confirmed the extensions were removed from the Chrome Web Store by Feb. 17, 2026, according to The Register’s reporting. Removal helps, but it doesn’t undo exposure for users who installed and used the tools while they were live.
30+
Number of malicious, AI-themed Chrome extensions described in February 2026 reporting, disguised as chatbots and productivity tools.
260,000+
The Register’s reported minimum installs for the campaign—enough to make DOM-based data siphoning a mass-scale risk.
Why people keep falling for it: trust signals that don’t measure risk
The uncomfortable truth is that users are not irrational. They are responding to the signals the ecosystem gives them:
- The extension requests few permissions.
- The UI looks modern and “AI-branded.”
- The workflow requires a click, implying consent.
- The store listing offers just enough legitimacy.
Meanwhile, the actual risk depends on factors users are rarely equipped to evaluate quickly: whether the extension can execute scripts on sensitive pages, whether it transmits data to remote endpoints, whether it embeds remotely controlled UI, and whether it can interact with privileged browser surfaces like side panels.
From the developer side, “minimal permission” designs are often responsible engineering. Asking for less access is usually better than asking for more. The flaw is not in least privilege as a goal; it’s in treating permission banners as a sufficient safety narrative.
- The extension requests few permissions.
- The UI looks modern and “AI-branded.”
- The workflow requires a click, implying consent.
- The store listing offers just enough legitimacy.
Meanwhile, the actual risk depends on factors users are rarely equipped to evaluate quickly: whether the extension can execute scripts on sensitive pages, whether it transmits data to remote endpoints, whether it embeds remotely controlled UI, and whether it can interact with privileged browser surfaces like side panels.
From the developer side, “minimal permission” designs are often responsible engineering. Asking for less access is usually better than asking for more. The flaw is not in least privilege as a goal; it’s in treating permission banners as a sufficient safety narrative.
Multiple perspectives: utility vs. exposure
A fair reading acknowledges competing realities:
- Users want AI tools that can summarize, draft, and extract content from pages. Those tools require reading content.
- Developers want fewer permissions because fewer prompts reduce friction and reduce the blast radius if something goes wrong.
- Security teams want clarity about where data can go and how interfaces can be subverted—especially when AI panels become “trusted screens.”
Those goals can align, but only if the ecosystem stops using permission minimalism as a proxy for harmlessness.
- Users want AI tools that can summarize, draft, and extract content from pages. Those tools require reading content.
- Developers want fewer permissions because fewer prompts reduce friction and reduce the blast radius if something goes wrong.
- Security teams want clarity about where data can go and how interfaces can be subverted—especially when AI panels become “trusted screens.”
Those goals can align, but only if the ecosystem stops using permission minimalism as a proxy for harmlessness.
What “minimal permissions” doesn’t tell you
Chrome prompts emphasize where an extension can run.
The real risk is what it can do with whatever you’re currently viewing.
A click can be the moment sensitive data leaves your browser.
The real risk is what it can do with whatever you’re currently viewing.
A click can be the moment sensitive data leaves your browser.
Practical takeaways: how to evaluate extensions and AI panels without paranoia
You don’t need to abandon extensions. You do need a better mental model: treat “can read what I’m viewing” as a powerful permission, whether it appears in a banner or hides behind `activeTab` and a click.
For individuals: safer habits that actually map to the threat
- Assume any extension you click can read the current page. If you wouldn’t paste the page contents into a third-party website, don’t invoke the extension there.
- Avoid using “summarize” tools on email and internal systems. The 2026 campaign targeted Gmail by reading visible content and drafts from the DOM.
- Be skeptical of AI-branded extensions that load remote content. Remote UI can change behavior without a store update, undermining the trust you place in review gates.
- Prefer narrow host access when possible. If you only need a tool on a few sites, restrict it to those sites rather than “all sites.”
- Avoid using “summarize” tools on email and internal systems. The 2026 campaign targeted Gmail by reading visible content and drafts from the DOM.
- Be skeptical of AI-branded extensions that load remote content. Remote UI can change behavior without a store update, undermining the trust you place in review gates.
- Prefer narrow host access when possible. If you only need a tool on a few sites, restrict it to those sites rather than “all sites.”
Personal rules of thumb
- ✓Assume a click grants read access to the active page
- ✓Don’t run AI “summarizers” inside Gmail or internal dashboards
- ✓Avoid extensions that can quietly change behavior via remote UI
- ✓Restrict host access to specific sites whenever possible
For teams: policy that matches modern browser reality
- Treat extensions as software vendors. Vet them, version them, and approve them the way you would any SaaS tool that touches sensitive data.
- Monitor for data exfiltration patterns. DOM extraction plus outbound network requests is the combination that matters.
- Harden around assistant panels. CVE-2026-0628 shows that privileged AI surfaces can become escalation targets. Threat models should include “extension-to-panel influence” paths.
- Educate users on outcomes, not prompts. Training that says “check permissions” fails if low-permission tools can still read and transmit sensitive content once invoked.
- Monitor for data exfiltration patterns. DOM extraction plus outbound network requests is the combination that matters.
- Harden around assistant panels. CVE-2026-0628 shows that privileged AI surfaces can become escalation targets. Threat models should include “extension-to-panel influence” paths.
- Educate users on outcomes, not prompts. Training that says “check permissions” fails if low-permission tools can still read and transmit sensitive content once invoked.
Editor’s Note
Least privilege is still good engineering. The failure mode is using “few permissions” as a substitute for understanding data flows and exfiltration paths.
The bigger lesson: the browser is becoming an operating system for trust
Browser security used to be about preventing websites from escaping their sandbox. That problem still matters. Yet 2026 adds a second layer: preventing code running “near the user” from inheriting the browser’s trust—whether through assistant panels, sidebars, or other agentic features.
The Gemini “Live in Chrome” vulnerability (CVE-2026-0628), disclosed by Unit 42 on March 2, 2026 and patched in early January, is a reminder that privileged UI surfaces can fail in ways that benefit attackers. The AI-themed extension campaign with 30+ malicious extensions and at least 260,000 installs is a reminder that attackers don’t need exotic exploits when they can persuade users to install the right code.
Most readers don’t need a new fear. They need a new rule of thumb: “zero permissions” is not a safety guarantee. It’s a description of how an extension asks for access, not what it can do when you invite it onto a page.
The next wave of browser assistants will be judged on usefulness. They should also be judged on containment. When the assistant can “see what you see,” the security boundary around that vision becomes one of the most valuable lines in consumer computing.
The Gemini “Live in Chrome” vulnerability (CVE-2026-0628), disclosed by Unit 42 on March 2, 2026 and patched in early January, is a reminder that privileged UI surfaces can fail in ways that benefit attackers. The AI-themed extension campaign with 30+ malicious extensions and at least 260,000 installs is a reminder that attackers don’t need exotic exploits when they can persuade users to install the right code.
Most readers don’t need a new fear. They need a new rule of thumb: “zero permissions” is not a safety guarantee. It’s a description of how an extension asks for access, not what it can do when you invite it onto a page.
The next wave of browser assistants will be judged on usefulness. They should also be judged on containment. When the assistant can “see what you see,” the security boundary around that vision becomes one of the most valuable lines in consumer computing.
“Zero permissions” is not a safety guarantee. It’s a description of how an extension asks for access, not what it can do when you invite it onto a page.
— — TheMurrow Editorial
T
About the Author
TheMurrow Editorial is a writer for TheMurrow covering explainers.
Frequently Asked Questions
Does “zero permissions” mean a Chrome extension can’t read my pages?
No. “Zero permissions” usually means the extension didn’t request broad, always-on permissions at install time. An extension can still run its own code and, with mechanisms like `activeTab`, gain temporary access to the current page when you click the extension. That access can be enough to read and extract on-page text.
What is `activeTab`, and why does it matter?
`activeTab` is a Chrome extension mechanism that grants temporary access to the active tab after a user gesture (often clicking the extension). It reduces persistent access, which is good, but it can still allow powerful page interaction in the moment—reading DOM content, extracting text, and potentially sending it to a remote server.
How did the 2026 malicious “AI chatbot” extensions steal Gmail data?
Reporting described extensions that read visible Gmail content directly from the DOM, extracting message and draft text via methods like `textContent`. Some also extracted page content using Mozilla Readability. The theft didn’t require “screen capture” in the cinematic sense; it relied on ordinary web-page access once the extension ran on Gmail.
What happened with CVE-2026-0628 and the Gemini “Live in Chrome” panel?
Palo Alto Networks Unit 42 reported on March 2, 2026 that a high-severity Chrome/Chromium vulnerability (CVE-2026-0628) could allow a malicious extension with basic permissions to inject code into the Gemini “Live in Chrome” side panel and inherit elevated capabilities. Unit 42 said Google fixed it in early January 2026, before publication.
Are AI side panels inherently unsafe?
Not inherently. They can be built with strong isolation. The risk is structural: AI panels are designed to access user context, so any isolation failure can be severe. CVE-2026-0628 illustrates how a privileged assistant surface can become an attractive escalation target when boundaries between extension code and panel content break down.
What’s the biggest warning sign when installing an extension that claims to be an AI assistant?
One major red flag is an extension that can interact with many sites and also loads remote content into its UI (for example via iframes). Reports on the 2026 campaign noted remote UI content that could change behavior without a store update, weakening the protection users assume comes from review gates.
