Cato Networks' research arm published details this month on DuneSlide, two critical vulnerabilities in the Cursor AI code editor tracked as CVE-2026-50548 and CVE-2026-50549, both rated 9.8 out of 10 on CVSS 3.1, according to SecurityWeek's coverage of the disclosure. The headline detail is the "zero-click" part: exploitation doesn't require a developer to approve a suspicious command or click anything at all. A prompt-injected instruction sitting inside content the AI agent simply reads, a file in the workspace, an MCP connector response, a search result pulled in while the agent does its job, can be enough to escape Cursor's sandbox and execute arbitrary code with the developer's own privileges, per further reporting from Cyber Security News.
How a stray prompt becomes code execution
The two flaws chain together. The first exploits improper sandbox boundary handling in how Cursor resolves its working-directory parameter; the second abuses symbolic link path resolution to bypass the editor's write protections. Neither requires memory corruption or an exotic exploit primitive, the kind of vulnerability that would normally take a skilled attacker weeks to weaponise. It requires getting text in front of the agent that looks like ordinary content but is read as an instruction, which is a much lower bar, and one that doesn't depend on tricking a human at all. Cato reported the flaws to Cursor privately on 19 February; Cursor's team initially closed the report, then reopened it and shipped fixes for both in the Cursor 3.0 release on 2 April, with the CVE identifiers formally assigned in early June.
That four-and-a-half-month gap between private report and public CVE is worth sitting with on its own. It's a reminder that "patched" and "publicly known" are different milestones with different implications for defenders: an organisation running Cursor in April had a fix available before most security teams had any way of knowing there was something to fix.
Why a patched flaw is still this week's problem
Cursor is reportedly running on developer machines across a majority of the Fortune 500, which is the detail that turns a single vendor's sandbox bug into a fleet-wide question. Patches existing since April doesn't mean every one of those installs is current: developer tooling upgrades lag behind server-side patching in most organisations, partly because IDEs are treated as personal productivity tools rather than production infrastructure, and partly because nobody owns the inventory of which laptop is running which version. Every Cursor build before 3.0 remains exploitable by DuneSlide, and unlike a server you can patch centrally, confirming that every developer's local install has actually updated is a genuinely harder inventory problem. We wrote last week about what Sophos found scanning endpoint telemetry for signs of coding agents behaving like intruders; DuneSlide is the other half of that picture, a case where the agent itself, not a misused feature of it, was the entry point.
There's also a supply chain angle. Our piece on secure software supply chains for regulated delivery teams treats developer tooling as part of the chain that needs the same scrutiny as third-party libraries; a code editor that can be silently turned into a remote code execution vector by content it reads while doing its job is exactly the kind of dependency that inventory should have flagged before Cato did.
The pattern underneath the specific bug
Strip away the Cursor specifics and DuneSlide is a preview of a broader category: AI agents that act on untrusted content as a normal part of their job, reading web pages, connector responses, files in a repository, are exposed to an attack surface that doesn't need a human to click, open, or approve anything. Traditional phishing still needs someone to take the bait. An agent that treats retrieved content as potential instructions doesn't. Our guidance on securing autonomous AI agents in production makes the same point about runtime agents; DuneSlide is evidence the same logic now applies squarely to the tools developers use every day, not just to production agent deployments.
- Confirm every developer machine running Cursor is on version 3.0 or later; treat this as an inventory exercise, not an assumption, since IDE upgrades rarely go through the same patch-compliance tracking as servers.
- Review what untrusted content your AI coding agents are permitted to read automatically, MCP connectors, web search, third-party repositories, and whether any of it can reach the agent without a human first triaging it.
- Treat AI coding agents as part of your software supply chain inventory, with the same vendor risk and patch-tracking discipline you'd apply to a build dependency.
- Ask your tooling vendors directly what sandbox model their AI agent uses and whether it has had an independent security review; a 9.8 CVSS zero-click flaw is not a hypothetical risk category any more.
- Build a rapid patch-adoption check into your engineering operating rhythm specifically for developer tools, since these updates are opt-in in a way production patching usually isn't.
Cursor fixed DuneSlide months before it became public knowledge, which is the system working as intended. The organisations still exposed today are exposed because of an upgrade gap, not a missing patch. If you'd like help auditing what your development tooling can read and act on without a human in the loop, email sales@halfteck.com.