Security researchers at SquareX have disclosed a critical vulnerability in the Comet AI browser by Perplexity, linked to a poorly documented Model Context Protocol (MCP) API and hidden built‑in extensions. The flaw, now patched, could in theory enable command execution on a user’s machine outside the normal browser sandbox. While Perplexity has silently rolled out a fix, the company has publicly criticized the research as “fake,” triggering an intense discussion about AI browser security and responsible disclosure.
Hidden MCP API and Privileged Built‑In Extensions in the Comet Browser
At the center of the issue is a little‑documented MCP API exposed to extensions as chrome.perplexity.mcp.addStdioServer. According to SquareX, this API was accessible to two non-removable, hidden extensions shipped with Comet: Agentic and Analytics. These components do not appear in the standard extensions interface, cannot be disabled by the user, and hold elevated privileges for interacting with MCP.
MCP (Model Context Protocol) is designed to connect AI agents to external data sources and local environments. In Comet, Agentic orchestrates automated AI “agent” tasks, while Analytics collects browser telemetry and monitors Agentic’s activity. Both are configured to communicate only with perplexity.ai subdomains, and access to the MCP API is formally restricted to those domains.
The security concern arises because the MCP API effectively provided a controlled path out of the browser sandbox. If misused, it could allow commands to be executed on the underlying operating system without explicit, granular permission prompts typical for dangerous actions. This moves the risk from mere data exfiltration to potential remote code execution (RCE), one of the most severe classes of vulnerabilities in browser security.
How the Comet Browser Attack Works: Extension Stomping and Code Execution
In its technical report, SquareX demonstrated a proof‑of‑concept (PoC) attack using a technique known as extension stomping—replacing or imitating a legitimate browser extension with a malicious variant. The researchers created a trojanized extension masquerading as the built‑in Analytics component and used it to invoke the MCP API indirectly via Agentic.
Because Agentic trusted the “replacement” Analytics extension, it forwarded commands that led MCP to execute processes on the host system. In a controlled test, SquareX was able to launch a copy of the WannaCry ransomware on a test machine. While this was only a demo, it showed that if perplexity.ai infrastructure or built‑in extensions were compromised, attackers could potentially deploy malware, spy on user activity, or steal sensitive data.
SquareX emphasized that other attack vectors—such as cross‑site scripting (XSS) on trusted subdomains, man‑in‑the‑middle (MitM) attacks, or supply‑chain compromise—might require minimal user interaction. Any breach of the Perplexity domain or update pipeline could have had broad, immediate impact across the Comet user base.
Perplexity’s Response to the Comet MCP Vulnerability
Perplexity has disputed the SquareX findings, publicly labeling the conclusions as “fake”. The company argues that the attack scenario is artificial and does not represent realistic risk, claiming that meaningful exploitation would effectively boil down to traditional social engineering and convincing users to install malicious software.
Perplexity further contends that the scenario described by SquareX would require an insider with production access to replace built‑in extensions, and that setting up local MCP endpoints and executing commands requires user confirmation. According to Perplexity, the video shared by SquareX shows an attack chain that still depends on substantial manual user actions.
The company also stated that it did not receive a full technical report from SquareX and that requests for additional details went unanswered, complicating the usual responsible disclosure process. This disagreement highlights ongoing tensions between security vendors and product developers over how and when to disclose high‑impact vulnerabilities.
Patch Status and Open Security Questions for Comet Users
SquareX reports that it notified Perplexity about the vulnerability on 4 November 2025, but did not initially receive a direct response. However, the researchers later confirmed that Perplexity had quietly deployed a fix to Comet: attempts to exploit the documented attack path now trigger an error message stating “Local MCP is not enabled”, and the previous PoC is no longer viable.
SquareX has welcomed the patch as a positive outcome that strengthens Comet’s security posture. At the same time, the lack of transparent communication and absence of a public security advisory raise questions about Perplexity’s vulnerability management, including how quickly and openly users are informed about critical AI‑related risks.
Expert Analysis: Systemic Risks in MCP and AI Browser Architectures
The incident illustrates a broader, structural issue: AI‑enabled browsers inherently expand the attack surface by introducing privileged agents and protocols that bridge cloud models with local resources. Even when access is restricted to a single trusted domain, any compromise of that domain, its TLS keys, or its software supply chain can transform this trust relationship into a powerful weapon for attackers.
From a security architecture standpoint, best practices dictate principle of least privilege, strong segregation of duties, and full transparency of privileged components. Hidden, non‑removable extensions with broad rights are at odds with this model. For critical interfaces like MCP, it is crucial to clearly define which actions can be performed locally, which require explicit, step‑up user consent (ideally with multi‑factor authentication), and which should be categorically inaccessible from a browser context.
Secure‑by‑Design Practices for AI Browsers and MCP
Modern secure‑by‑design guidance for AI tooling recommends detailed threat modeling of agent capabilities, rigorous sandboxing, robust logging, and public documentation of all privileged APIs. Bug bounty programs, clear security changelogs, and independent audits further increase trust and make it less likely that critical issues remain unnoticed or unreported.
Practical Security Recommendations for AI Browser Users and Developers
For users of Comet and similar AI browsers, it is essential to keep software up to date, apply patches promptly, and exercise caution with third‑party extensions or downloaded executables. Complementary protections—such as reputable EDR/antivirus solutions, regular offline backups, and the use of non‑administrative user accounts—can significantly reduce the impact of a successful exploit or ransomware incident.
For developers of AI browsers and MCP‑based platforms, priority should be given to secure‑by‑design architecture for MCP and agent extensions. This includes transparent listing of built‑in components, options to disable or restrict them, fine‑grained permission models, robust code‑signing and update validation, and public documentation of any API that can reach beyond the browser sandbox. Investing in threat modeling, red‑teaming, and bug bounties helps surface complex attack chains before they can be abused at scale.
The story of the MCP API in Comet underscores that the rapid integration of AI agents into browsers introduces new classes of systemic risk. Balancing innovation with security will require close cooperation between users, browser vendors, AI service providers, and the security community, along with sustained attention to how and when AI is allowed to access local resources.
