Two Zero-Click Bugs in Cursor Let a Web Page Run Code on Your Laptop. If You Use Cursor, You Patch This Weekend.

Cato AI Labs disclosed a pair of Cursor vulnerabilities this week they're calling "DuneSlide": CVE-2026-50548 and CVE-2026-50549, both scored 9.8 on the older CVSS scale. The short version: you type a normal prompt, your agent fetches some content on your behalf, and instructions hidden in that content escape Cursor's sandbox and run commands directly on your machine. No approval dialog. No click. The flaws were fixed in Cursor 3.0. Anything older than that is exposed. The problem is how many people running Cursor right now never noticed the update and are still on a pre-3.0 build.

If Cursor is your daily editor, stop reading at the end of this paragraph and go check your version. If you're not on 3.0 or later, update. Then come back, because the fix is the easy part and the lesson underneath is the part that keeps mattering after this specific CVE is forgotten.

What zero-click actually means here

The word doing the work is "zero-click." Most prompt-injection scares still assume you do something: paste a sketchy prompt, open a file you shouldn't, click "approve" on a command you didn't read. DuneSlide doesn't need any of that.

The attack rides in on content your agent reads for you. Cursor, like every agentic editor, pulls in external context: a page returned by a web search, a response from a connected Model Context Protocol server, the contents of a repo. An attacker plants instructions inside one of those sources. You ask Cursor something completely innocent. The agent goes and fetches the poisoned context as part of answering, the hidden payload gets treated as instructions, and the two bugs let it break out of the sandbox to write files and execute commands at the OS level, outside the walls that were supposed to contain it.

You never see it. That's the whole point. The malicious input and the person typing are two different parties, and the sandbox that was supposed to sit between them had a gap.

Why this hits solo operators harder than it hits a company

A big engineering org runs Cursor on a locked-down work laptop with no production credentials on it, network egress controls, and an IT team that pushes the update whether you like it or not. That's not you and it's not me.

The solo operator setup is one machine. It's the editor, sure, but it's also where your .env files live, where your SSH keys sit in ~/.ssh, where you're logged into the cloud CLI with credentials that can spin up infrastructure, and where the deploy script has whatever it needs to push to prod. When an exploit gets OS-level execution on that machine, it isn't reading your code. It's reading everything.

And here's the uncomfortable framing: the attacker didn't compromise your laptop. Your own AI agent did, carrying the payload in as part of doing exactly what you asked. The tool you adopted specifically because it reads external context and acts on it is the tool that read hostile external context and acted on it. That's not a bug in your workflow. It's the workflow.

This is the third time, not the first

If DuneSlide feels familiar, it should. It's the same shape as GuardFall, the command-allowlist bypass that broke roughly ten open-source coding agents a few weeks back, where the filter checked one string and the shell ran a different one. It's the same shape as the Claude desktop trusted-process chain that got argued about in late June. Three different products, three different research teams, one recurring lesson: a text-based approval gate is not a security boundary when the thing behind it reads untrusted content and can run commands.

The industry keeps shipping the same mental model, "we'll inspect the command and ask the user before anything dangerous runs," and attackers keep pointing out that inspection and execution look at different things, or that the user never gets asked at all. Allowlists, approval prompts, and "safe command" heuristics are useful. They are not a wall. Isolation is the wall.

What I'd actually do

Update Cursor to 3.0 or later first. That closes these two specific CVEs and it costs you thirty seconds. Do it now, not "later."

Then treat the update as the floor, not the ceiling, and change three things about how you run any agentic editor.

Audit your MCP connections. Every MCP server you've wired into Cursor is a source your agent trusts and reads. Open the list, and if there's a server you added once to try something and never removed, drop it. You want the count as low as it can be, and every remaining one should be something you control or genuinely trust, because each is a channel for exactly this class of attack.

Stop running the agent with ambient production credentials. This is the big one and it's the one people skip because it's mildly annoying. The blast radius of an OS-level exploit is defined entirely by what that machine and that user can reach. If your prod database URL and your cloud admin keys aren't sitting in the environment the agent runs in, a sandbox escape gets a lot less catastrophic. Scope your keys, use short-lived credentials, and keep the stuff that can wreck you off the machine where an autonomous agent reads web pages.

Treat web search and MCP responses as untrusted input, permanently. Not "until this is patched." Permanently. The whole value of an agent is that it reads the outside world and acts on it, which means the outside world is now part of your attack surface whether or not there's a CVE that week.

Here's the honest counter-take, because it's worth saying: none of this means Cursor is uniquely unsafe or that you should rip it out. Cato disclosed responsibly, Cursor patched, that's the system working. Every agentic editor has this exposure because the capability and the vulnerability are the same feature. The mistake isn't using these tools. The mistake is running them like they're a text editor when they're actually a program that executes untrusted instructions on your behalf. Patch this weekend, then build the isolation you should have had before the CVE gave you a reason to.

Author

Lukas

@lukcombinator

Sources

• DuneSlide: Two Critical RCE Vulnerabilities via Zero-Click Prompt Injection in Cursor IDE — Cato Networks
• Critical Cursor Flaws Could Let Prompt Injection Escape Sandbox and Run Commands — The Hacker News
• Critical Cursor AI Code Editor Flaws Could Lead to OS-Level Remote Code Execution — SecurityWeek
• Sandbox bypass flaws in Cursor IDE highlight prompt injection as an RCE vector — CSO Online