Five browser agents fell to one extension. Extension policy is now an agent security control.

Forever Security reported on 16 September that one Chromium extension could compromise AI-assistant trust paths across five environments: Gemini in Chrome, Perplexity Comet, Microsoft Edge, Opera Neon and Claude in Chrome. The research produced two CVEs and about $20,000 in combined bounties. Google separately records CVE-2026-0628 as a high-severity policy-enforcement flaw in Chrome's WebView tag.

The obvious reading is that browser extensions remain dangerous. That is true but incomplete. The more important change is that an extension can now reach a component that can reason about a goal and operate privileged browser capabilities on the user's behalf.

The trust channel is the security boundary

Forever Security calls the technique prompt forcing. Instead of hiding instructions in content for a model to interpret, the attacks targeted trusted communication paths between an AI "brain" and a privileged browser "body". The exact path varied by product, but the recurring weakness was architectural: code that could influence a trusted origin or message channel could cause an agent to accept attacker-selected instructions.

An agent's command channel deserves the same threat model as an administrative API.

That distinction matters operationally. Model guardrails are downstream of the failure. If untrusted extension code can become an authorised instruction source, filtering the resulting prompt does not restore the lost privilege boundary.

The impact also depended on the browser implementation. Forever Security demonstrated combinations of local-file access, screenshots, profile or history exposure, camera and microphone access, and agent-driven actions. Its "zero click" result describes exploitation after the malicious extension was already installed; it is not a claim that an arbitrary website could compromise an unmodified browser.

Extension governance now belongs in the agent control plane

Enterprises deploying browser agents should inventory extension permissions alongside agent tools and identities. Broad host access, declarativeNetRequest, debugger access and permissions over origins trusted by an assistant deserve explicit review. Allowlisting extensions is no longer only a browser-hardening measure; it constrains which code can influence the agent's authority path.

The second control is architectural. Vendor and enterprise designs should minimise the set of origins allowed to issue agent commands, authenticate messages across the browser-to-agent boundary, and require fresh authorisation before sensitive actions. A marketing page, test domain or privileged webview should not silently inherit the authority of the agent itself.

Detection has to follow actions, not only payloads

The research also exposes a telemetry gap. A compromised agent may perform legitimate browser actions rather than execute a recognisably malicious binary. Security teams therefore need to correlate extension installation and permission changes with agent actions, identity events, file access and unusual activity in authenticated applications.

The practical review question changes. Do not ask only whether the model can resist prompt injection. Ask which local components can submit commands to the agent, what authority those commands inherit, and whether security telemetry can reconstruct the resulting action chain.

Written by the Devence Lab research team.