We walk through how Cursor’s new browser could be compromised via JavaScript injection. Unlike VS Code, Cursor does not perform integrity checks on Cursor-specific features. That difference makes Cursor’s runtime components a higher-risk target for tampering. We demonstrate this by registering a local MCP server, which completely circumvents Cursor’s controls.
In the blog, we demonstrate this insecurity by replacing the login pages within Cursor’s internal browser with a page that harvests credentials and sends them to a remote attacker. We also show how that same capability allows an attacker to compromise a victim’s workstation. The attack also works as a VS Code extension.
Since MCP servers also require broad permissions to function, it can be catastrophic when MCP servers are abused: components can modify themselves, escalate privileges, and gain new capabilities without user visibility.
While the attack itself is new, the underlying issues are not, and we’d like to tip our hat to others who walked this path before us, such as Johann Rehberger. We’d also like to note that Cursor was notified prior to publication.
Developers and coding agents are actively targeted via malicious MCP servers, IDE extensions, prompts, and rules. These attacks expand the CI/CD boundaries onto the developer’s machine, which effectively becomes the new cyber defense perimeter, and expand supply chain risk for the enterprise.
Knostic protects your developers and AI coding agents from these new supply chain attacks. To learn more, visit https://www.knostic.ai/ai-coding-security-solution-kirin
First, we created a PoC of a malicious MCP server, then implemented a script to modify internal, unverified code for when an MCP server is registered (on the tools/list command). This allowed us to inject arbitrary code and hijack the internal browser.
Once a user downloaded the MCP server and ran it, using an mcp.json file within Cursor, it injected code into Cursor’s browser that led the user to a fake login page, which stole their credentials and sent them to a remote server.
For safety, we do not publish exploit code here. Instead, we describe the mechanism, how to detect it, and how to mitigate it.
First, we found Cursor's extension within Cursor’s local extensions directory. No permissions were required and no checksum recalculation in product.json was needed (although that recalculation was not fully effective to begin with, as we demonstrated in a previous blog post where we overrode the checksum using OpenSSL).
Next, we assigned document.body.innerHTML = [HTML_PAYLOAD], which overwrote the entire page body, erased prior DOM state, and sidestepped UI-level checks. This ensured the attacker-controlled content was what the user saw.
Then, we searched for the browser-tab-id and replaced it with a payload. The code executed a command in Cursor to run JavaScript inside the embedded browser. It was effectively an eval on top of another eval. From that point on, every browser tab Cursor opened executed the code.
For this to fully propagate:
Coding agents introduce a new attack surface that expands daily. In this example, we demonstrated how Cursor does not perform integrity checks on Cursor-specific features, unlike VS Code.
We generated a credential-stealing web page that sent credentials to a remote server, but the MCP server could perform any action the user could, with no controls in place to mitigate the risk.
The new supply-chain risks associated with agents are significant, and organizations have minimal visibility into their use. MCP servers, extensions, and even simple prompts can potentially execute code in a user’s environment, and by extension, the corporate network, without their knowledge.
Triple-check every MCP and extension you add. Try to find the project’s GitHub repo and review the code. This is a program you install on your computer that can do anything. If there’s doubt about its credibility, DO NOT USE IT.
Never blindly enable anything, especially MCP functionality.
Refrain from using auto-run modes.
Don’t assume that everything your AI agent generated is as you expected. Read through the code before performing actions in the embedded browser.
And:
Consider using Knostic’s Kirin for proactive protection.
Knostic’s Kirin protects agents, specifically developers and AI coding assistants, against supply chain attacks like these by providing detection and response, posture management capabilities, a comprehensive inventory, and a reputation system for safe ingestion.
Learn more: https://www.knostic.ai/ai-coding-security-solution-kirin
Credit to Dor Munis for the research.
Thanks to:
Heather Linn, Sarah Levin, Michael Bargury, Idan Habler, Ari Marzouk (MaccariTA), Sounil Yu, and Gadi Evron.