Browser Extensions as AI Agent Backdoors: Claude Dispatch Abused for Arbitrary Code Execution

A Vulnerability Without a CVE: How a Malicious Extension Turns AI Agents Into an Execution Vector

Security researchers recently demonstrated an attack path in which a malicious browser extension with only script-access permissions can abuse an AI web platform's task-relay feature to trigger arbitrary code execution on the user's local machine. There is no traditional exploit anywhere in the process—no CVE number, no memory corruption, no bypassing of any protection mechanism. A poisoned extension sitting quietly in the AI workflow chain is all it takes.

The key to this attack chain is misplaced trust. From the AI agent's perspective, the instructions it receives come through a "legitimate" relay channel; from the user's perspective, that channel has already been compromised by a browser extension. The extension doesn't execute malicious code directly—it simply hands a forged or tampered task to the AI agent, which then "does the work" of local execution on its behalf. The attacker doesn't need to breach the AI platform; they only need to breach the input endpoint the platform trusts.

Task-relay is a common class of component in AI agent platforms, used to pass pending task descriptions between different sessions, devices, or integrations. After reading a task from the relay channel, the agent typically doesn't distinguish who originally created that task—it simply dispatches local capabilities based on the content. This design improves the convenience of cross-device collaboration, but it also makes the relay channel a critical node in the trust chain: anyone who can write to it can indirectly influence agent behavior.

The Attack Surface Far Exceeds Design Assumptions: Browsers, Third-Party Integrations, and Mobile Handoffs

The attack surface of AI desktop agents has already far exceeded the assumptions most security models were designed around. Researchers point out that browsers, third-party integrations, and mobile handoffs all expand the exposure. Every new input channel an agent accepts is a potential injection point.

The browser extension ecosystem deserves particular scrutiny in this chain. Relative to the level of trust AI agents grant it by default, the extension ecosystem receives fairly limited review. An extension may request only seemingly mild permissions like "read and modify page data," but once the page is an AI platform's interface, that permission is enough to tamper with task content. The permission model is organized around web page capabilities, while risk is amplified by the AI agent's execution capabilities—a clear mismatch between the two.

Mobile handoffs deserve attention as well. When tasks flow between a desktop agent and a mobile device, every handoff point can become a new injection surface. The researchers did not provide specific attack demonstration details, but based on the attack logic, any link that can write to the relay channel has the potential to become a poisoning point.

Browser extension permission models are typically organized around accessible web page capabilities, such as reading and modifying page data (e.g., the activeTab, scripting permissions). These permissions are granted to enhance web page functionality, and the review focus is on whether the extension abuses page content—not on whether it can influence other applications running on the same page. If an AI agent platform presents its task interface as a web page, an extension may be able to rewrite task content without the user's awareness, and the permission model itself will not flag this behavior as a privilege violation.

A Structural Problem: Agents Execute What They Receive, but Instruction Provenance Is Rarely Verified at Execution Time

What this demonstration exposes is a structural problem, not an incidental flaw in a particular product: agents execute what they receive, and the instruction provenance is rarely verified at the execution point. From the agent's perspective, a relay poisoned by an extension is functionally identical to a legitimate relay.

This means that building a security boundary solely on the assumption of "trusted source" is insufficient. When an agent treats external input as instructions to execute, the trustworthiness of the input channel directly determines the trustworthiness of the execution result. The problem is that many AI agents are architected to trust the browser environment, third-party integrations, and mobile handoffs by default, without independently verifying instruction provenance at the execution point.

Instruction provenance refers to independently confirming that an instruction was actually issued by the expected party before executing an action, rather than relying solely on the trustworthiness of the transport channel. Common implementations include signing task descriptions, verifying source identifiers at the orchestration layer, or requiring secondary confirmation for sensitive operations. Without this layer, the agent can only substitute "trusted channel" for "trusted instruction," and once the channel is compromised, the agent cannot distinguish legitimate tasks from injected content.

The Real Problem for Enterprise Environments: Which Layer Should Enforce Execution-Time Constraints?

For teams running AI agents in production or enterprise environments, this attack path raises a concrete question: regardless of what the agent is told to do, how do you constrain what it is actually allowed to do? Should this enforcement happen at the host layer, the orchestration layer, or somewhere else?

From a defensive perspective, several directions are worth considering: restricting the system capabilities an agent can invoke at the host layer, so that even poisoned instructions struggle to reach sensitive operations; independently verifying task provenance at the orchestration layer instead of trusting the relay channel by default; and applying finer-grained control over browser extension permissions, especially for extensions that can access AI platform interfaces.

The researchers' demonstration doesn't offer a universal solution, but it points in a direction: security boundaries cannot be built only on "who sent the instruction," but also on "what is allowed to happen at execution time." When instruction provenance is hard to verify, execution-time capability constraints are the last controllable line of defense.

Frequently Asked Questions

Is this a vulnerability in the Claude platform itself?

What the researchers describe is a malicious browser extension abusing the AI platform's task-relay feature, not a traditional vulnerability in the platform itself. The attack relies on the extension's access to page scripts and the agent's trust in the relay channel.

Should ordinary users worry?

The risk depends mainly on the trustworthiness of the browser extensions installed and on whether the user is running an AI agent with local execution capabilities. For enterprise environments, this attack path is worth incorporating into threat model assessments.

Is there a CVE or a patch?

The researchers explicitly state that there is no CVE and that this is not a traditional exploit. The defensive approach leans toward architectural execution-time constraints rather than a point patch.