Cursor’s Magic Comes with a Catch: The Trust Setting You’re Missing

Occasionally, a new AI tool emerges unexpectedly and dominates the conversation on social media. This time, that tool is Cursor, an AI coding platform that’s making waves for simplifying app development with advanced models like Claude 3.5 Sonnet and GPT-4o.

In a recent video posted on X, which has already garnered over 2 million views, an eight-year-old aspiring coder demonstrated Cursor’s capabilities by effortlessly creating a Harry Potter-themed chatbot. With just a few prompts, she guided the AI to bring her vision to life, marveling at how quickly and effectively the tool executed her ideas. But it’s not only beginner developers who see the appeal in Cursor–prominent figures in the tech community, like Andrej Karpathy, have also taken notice. Karpathy, a well-known AI researcher and former Director of AI at Tesla, recently shared his thoughts on Cursor via X:

Programming is changing so fast… I’m trying VS Code Cursor + Sonnet 3.5 instead of GitHub Copilot again and I think it’s now a net win. Just empirically, over the last few days most of my “programming” is now writing English…

Cursor’s growing popularity isn’t just due to its impressive AI capabilities—it’s also because the platform is based on Visual Studio Code (VS Code). This makes it particularly appealing to existing VS Code users, as it allows for a seamless transition. All the familiar extensions and settings that developers have customized over time work effortlessly with Cursor, making it easy to adopt without needing to overhaul one’s workflow. However, while Cursor inherits many of the strengths of VS Code, it also brings along some of the security baggage associated with it.

VS Code’s Safety Net That Cursor Cut Loose

Image 1 Trust Sign

The introduction of “Workspace Trust” in Visual Studio Code was a necessary step to enhance user security. Before this feature, opening a workspace in VS Code could unintentionally execute scripts, tasks, or extensions without the user’s explicit consent, potentially exposing the system to malicious code. This posed a significant risk, particularly through supply chain attacks where trusted-looking projects could contain harmful commands. With “Workspace Trust,” users now have greater control over what code is allowed to run, reducing the chances of inadvertently compromising their system.

In contrast, we found that Cursor chose to disable this security feature, opting for convenience over safety. While this decision might streamline the user experience, it also exposes developers to greater risks. Without the safeguards provided by “Workspace Trust” Cursor users are more vulnerable to malicious scripts and hidden threats embedded in projects. This trade-off could lead to severe security implications.

Viewing Code = Running Malware

It’s very common for developers to clone or download open-source projects and quickly open them in their editor to search through code, debug, or explore new ideas. However, this seemingly harmless habit can become a significant security risk, especially with Cursor.


 

By creating a folder with a nested “.vscode” folder and a “settings.json” file, an attacker could overwrite extremely sensitive settings such as “php.validate.executablePath“. This setting can automatically execute any binary file specified in it. By pointing it to a relative path like “./.vscode/run”—an attacker could execute arbitrary shell commands on the user’s machine as soon as the user merely views a PHP file. This means that simply opening a project could silently compromise your system.

Image 2 Json Code Snip

You can find our proof of concept code here. Since the file we are executing is a bash script, it will only work on macOS and Linux machines. However, the same attack can be performed on a Windows machine with minor modifications.

Historical Context and Disclosure

We were surprised to learn that we were not the first to notice this issue. In November 2023, a GitHub issue was raised highlighting this exact problem. The maintainer responded by pointing out that in Cursor, Workspace Trust is disabled by default, and users can enable it by setting “security.workspace.trust.enabled” to true.

Image 3 Thank you

We have since reached out to Cursor to ensure they fully understand the potential consequences of disabling this feature, but unfortunately, we have not yet received a response.

Conclusion

Recent attacks on developers, such as the campaign by North Korean hackers targeting developers with malicious npm packages, have highlighted the increasing risks of supply chain attacks in software development. These attackers have been publishing seemingly useful tools or libraries on the npm registry, which, once installed, execute malicious scripts designed to steal sensitive information or cryptocurrency.

In light of these threats, it becomes clear that Cursor, while offering an exciting and powerful tool for developers, also presents security trade-offs that must be carefully considered. Disabling the “Workspace Trust” feature might make the coding experience smoother, but it significantly increases the risk of malicious code execution. Therefore, we strongly urge all users to manually enable “Workspace Trust” by setting “security.workspace.trust.enabled” to true in their settings. This simple step can protect your system from potential threats. Balancing usability and security is always a delicate act, but in this case, safeguarding your work environment should take precedence.

The post Cursor’s Magic Comes with a Catch: The Trust Setting You’re Missing appeared first on Blog.