On 1 July 2026, the Cato AI Labs research team disclosed two critical flaws in Cursor, one of the most widely used AI code editors. They named them DuneSlide, assigned them CVE-2026-50548 and CVE-2026-50549, and a critical score (9.8 on CVSS 3.1; 9.3 on CVSS 4.0). What they allow, in short, is for a prompt injection to escape the editor's sandbox and run arbitrary commands on the developer's machine, with no extra click.
The interesting part is not one more flaw in one more editor. It is the confirmation of something we had watched approaching for months: prompt injection has stopped being an academic curiosity and become a real route to code execution, inside tools that developers already run with access to source code, secrets and the internal network. The patch exists, but the lesson outlives the patch.
What exactly goes wrong
An AI editor's agent reads content on your behalf: project files, web pages, responses from services connected through the Model Context Protocol (MCP). If that content carries hidden instructions, known as indirect prompt injection, the agent may end up acting on them as if they were yours. To limit the damage, Cursor runs the agent's commands inside a sandbox. DuneSlide is precisely about escaping that sandbox. The technical write-up from Cato lays it out at a conceptual level.
The first flaw, CVE-2026-50548, leans on the fact that the sandbox trusts the working folder the agent chooses. If injected instructions point that folder at a system path rather than the project, the door opens to overwriting the very component that enforces the sandbox, so later commands run with no barrier at all. Put broadly: the guard is tricked into switching itself off.
The second, CVE-2026-50549, lives in a safety check on symbolic links. Before writing, the editor tries to resolve the link to confirm the real destination sits inside the project; when that check fails, rather than refusing, the editor chooses to trust the apparent path. It is the wrong default. Both flaws, as The Hacker News underlines, fire with no deliberate interaction: the victim only issues an innocuous request that unknowingly ingests attacker-controlled content.
The vector is not the user: it is what the agent reads
Here is the shift in mindset. The attack does not land by fooling the person, but by poisoning what the agent consumes: an MCP server's response, a page returned by a web search. The developer's intent is legitimate; the untrusted content carries the payload. That is the essence of indirect prompt injection, and it is why training people not to click odd links is not enough.
Why this is a business problem, not one developer's
These editors run with the developer's privileges: they read and write source code, they see the credentials and tokens in that environment, and they can reach the internal network. A sandbox escape there is not a nuisance on one laptop: it is a foothold inside your development lifecycle, with access to what genuinely matters.
On top of that, adoption is broad and often invisible to security. Developers install AI editors and MCP connectors on their own, without passing through any control. The inventory question, which agentic tools touch our code and with what permissions, is one many organisations cannot answer. It is shadow AI inside development itself, and it widens the attack surface along a flank almost nobody watches.
The data, and what it confirms
DuneSlide is two vulnerabilities, CVE-2026-50548 and CVE-2026-50549, both critical, discovered by Cato AI Labs and fixed in Cursor 3.0, released on 2 April 2026. Every version before 3.0 is affected. It is worth being honest about the nuance: the flaw is disclosed now, but the fix has been available since 3.0; the urgency is in checking which version your team runs, not in a zero-day panic. CSO Online's coverage frames well why this reaches beyond Cursor.
And it is no isolated case. Independent research describes the same class of problem: Straiker's work on Cursor's remote tunnel and academic analysis of agentic editors show that indirect prompt injection can be weaponised through the editor's own features. The story is not one loose bug but the pattern. As far as is known, the disclosure comes from researchers and there is no public evidence of mass exploitation in the wild; saying so plainly is part of reporting it well.
Why traditional controls fall short
No malicious binary lands: the malware, so to speak, is the text the agent reads. Antivirus and EDR signatures do not map cleanly onto something that is not a file. The mail gateway and the WAF are not in the path. The trust boundary that fails sits inside the tool, between what the model reads and what it is allowed to do. Classic perimeter thinking simply does not look there.
Identity and MFA do not help either: the agent already runs as the legitimate developer. There is no suspicious sign-in to block, because there is no sign-in. There is a trusted tool doing something it should not, because it read something it should not have.
Concrete detection and containment
With endpoint visibility on developers' machines there are usable signals. Unexpected child processes spawned by the editor, writes into the application's paths or its internal components, or new outbound connections, especially a remote tunnel opened out of nowhere, are exactly the sort of anomaly worth an alert. A coding agent that starts writing outside the repository or opening a tunnel is the event to hunt.
Egress control in development environments sharply bounds the impact: if the agent cannot exfiltrate or download a second stage, the sandbox escape is worth far less. Logging and reviewing which MCP servers connect, and treating every agent tool call, web search included, as untrusted input crossing a boundary, turns a black box into something auditable.
And the inventory piece is unavoidable. Knowing which AI editors and which versions are in use, and checking that against their vulnerability status, is classic vulnerability management applied to a new category of tool. You cannot protect what you do not know is installed.
Practical defence
The first step is the dullest and the most effective: make sure Cursor and equivalent editors run fixed versions, 3.0 or later in Cursor's case, and do it centrally where you can. Adding these tools to the inventory you already manage stops the next vulnerability in this family from catching you without even knowing where it lives.
Next, least privilege for agents. It is unwise to run them with broad access to the file system, to secrets or to the network; scoping the working folder, keeping credentials out of the environment the agent can read, and requiring human approval before running commands, where the tool allows it, completely changes the worst case.
It also helps to limit what they feed on. Restricting which MCP servers and external sources an agent may consume, preferring trusted and pinned connectors, and distrusting agents that automatically fetch arbitrary web content all reduce the raw material of the attack.
None of this replaces a policy. Deciding which AI coding tools are approved, with what configuration and what permissions, and pairing that with developer guidance, is what separates governed use from a free-for-all. We covered this when discussing production controls for MCP and enterprise AI agents and when reviewing consulting on secure practices.
A prepared response matters too. If a workstation running an agent is suspected of compromise, incident response must hold source access, the tokens present and possible lateral movement within its scope. In network terms, the developer is a user carrying a great many keys.
What it means for NIS2 and DORA
NIS2 expects security measures in development and in the software supply chain, and governing the tools with which that software is built falls squarely into that territory. DORA requires financial entities to manage ICT risk, including the risk of the tools and providers involved in their systems. In both frameworks, a category of tool capable of running code with the developer's permissions is not a productivity detail: it is ICT risk to be managed and documented.
The honest conclusion is that the patch is the easy part. The underlying problem endures: as agents gain autonomy and read more untrusted content, the idea that the input is the exploit becomes a permanent design constraint. The sensible posture is to treat every source an agent reads as hostile until proven otherwise, and to give each agent the least power that still lets it do its job.