CVE Finding: When Opening a Folder Is the Same as Running a Script

A silent code-execution risk in Cursor IDE — and what IT managers should do about it

If anyone on your team uses Cursor IDE, simply opening a project folder can run code on their laptop — with no prompt, no warning, and full access to everything that user can touch.

If that sentence made you pause, keep reading. This takes five minutes and the fixes are free.

Why this matters for an SME

Most small and mid-sized businesses don't have a dedicated security team watching developer laptops. Those laptops, however, often hold the keys to the kingdom: SSH keys, AWS or Azure credentials, VPN access, customer data, and the source code that is your product.

AI-powered IDEs like Cursor are spreading fast through engineering teams because they make people genuinely more productive. The problem is that they also introduced a new category of risk that traditional security training doesn't cover yet:

Opening a Git repository is no longer a passive action. It can be an executable one.

What's actually happening

Cursor supports a feature called hooks — small automation scripts a project can ship inside a hidden .cursor/hooks.json file. They were designed to make the AI assistant smarter about a specific codebase.

In practice, they behave like this:

• A developer clones or opens a repo (open source, a contractor's code, a candidate's coding test, a forked dependency — anything).
• Cursor reads .cursor/hooks.json from inside the project.
• Whatever is in that file runs immediately, as the logged-in user.
• There is no sandbox. No "Are you sure?" prompt. No log entry the user will notice.

The IDE's "Workspace Trust" safety net — the feature that's supposed to ask before running project automation — is off by default in Cursor.

What that means in business terms

The reach of the attack is whatever your developer's laptop can reach. For most SMEs, that's a lot.

Why your existing defences may not see it

• Antivirus and EDR see Cursor as a legitimate, signed application. The malicious activity looks like normal developer behaviour.
• Code review rarely scrutinises hidden IDE config folders. Reviewers wave through .cursor/ the same way they wave through .vscode/.
• Workspace Trust would help — but it's disabled by default, so most users never see a warning.
• The user never typed a command. They just opened a folder. There is nothing for training to point at.

The fix is mostly free

You don't need a new tool. You need three habits.

1. Treat IDE config folders like executable code

Before opening any repo from outside your organisation — third-party code, contractors, candidates, dependencies you're evaluating — take 30 seconds to look inside:

• .cursor/ (especially hooks.json and mcp.json)
• .vscode/ (tasks.json, settings.json, launch.json)
• .devcontainer/
• .husky/ and .git/hooks/

If you wouldn't run a random script from that repo, don't open it in Cursor before checking these files. A quick look in a plain text editor is enough.

2. Audit the user-level config too

The personal Cursor config lives at ~/.cursor/ on macOS/Linux or %USERPROFILE%\.cursor\ on Windows. Once a quarter (or as part of routine endpoint hygiene), check:

• ~/.cursor/hooks.json
• ~/.cursor/mcp.json
• ~/.cursor/rules/

Anything there that the developer didn't put there themselves is a red flag — investigate it.

3. Don't open unknown code on a privileged machine

For evaluating outside code — dependencies, contractor work, coding tests — use a throwaway environment: a VM, a container, or a dedicated review laptop with no production credentials, no SSH keys, no cloud profiles. Cursor's remote-SSH and dev-container features make this painless

A 5-minute checklist you can send to your team today

• [ ]  Turn on Workspace Trust in Cursor settings.
• [ ]  Before opening any external repo, glance at .cursor/, .vscode/, .devcontainer/.
• [ ]  Don't review untrusted code on a laptop holding production secrets.
• [ ]  Once a quarter, audit ~/.cursor/ for files you didn't put there.
• [ ]  Tell developers to report anything weird in those folders to IT.

Bonus, if you have endpoint visibility

While changing developer habits closes the most gaping holes, humans will always make mistakes. A busy engineer will eventually open an untrusted folder without checking .cursor/hooks.json first. That is where deep endpoint visibility changes the game.

Because Cursor runs these scripts locally, a managed endpoint detection and response (EDR) or Managed Detection and Response (MDR) service provides a critical safety net. Instead of relying on traditional antivirus—which looks for static file signatures and completely misses these dynamic script executions—an MDR team monitors real-time system behaviors.

Having a dedicated MDR service is helpful for three primary reasons:

• Behavioral Anomaly Detection: When a text editor or IDE suddenly spawns a background shell to execute an outbound curl request to an unknown IP address, or attempts to read ~/.ssh/id_rsa, an MDR team flags it instantly. They see the action, not just the app.
• Contextual Alert Triaging: Developers legitimately run weird scripts all day. A standalone security tool might flood your inbox with false positives, leading to alert fatigue. An MDR service brings human experts into the loop who can instantly differentiate a routine local build script from a hidden .cursor/ exploit stealing session cookies.
• Immediate Blast-Radius Isolation: If a weaponized repository is opened and successfully triggers an exploit, seconds matter. An MDR service doesn't just send you an email; it can automatically isolate the compromised laptop from the network, cutting off the attacker before they can use lifted AWS keys or pivot deeper into your production environment.

In short: endpoint hygiene blocks the attack, but behavioral endpoint visibility ensures you aren't blindsided if a developer slips up.

The bottom line

AI coding tools are here to stay, and they're a productivity win. But the trust boundary has shifted: opening a folder is now an action, not a passive one. A short habit change — audit IDE config files like you'd audit any other executable — closes off the bulk of the realistic risk at zero cost.

If your developers are running Cursor (or any AI IDE), make this part of your onboarding pack this week. It's a five-minute fix for a high-impact exposure.