Summary
- Cato AI Labs disclosed two critical Cursor IDE vulnerabilities, CVE-2026-50548 and CVE-2026-50549.
- The research says prompt injection could lead to arbitrary file writes, sandbox escape, and non-sandboxed remote code execution.
- The exposure sits inside developer tooling, where source code, secrets, SaaS workspaces, and build environments concentrate enterprise risk.
Cato Networks says two critical vulnerabilities in Cursor show how prompt injection can move beyond the language model layer and reach the developer workstation beneath it.
The vulnerabilities, which Cato AI Labs calls DuneSlide, affect Cursor IDE and are tracked as CVE-2026-50548 and CVE-2026-50549. Cato says both achieved a CVSS score of 9.8 and involved breaking out of the IDE’s sandbox environment. The flaws were disclosed through a responsible disclosure process and fixed in Cursor 3.0.
The research describes a path from zero-click prompt injection to arbitrary file write, sandbox escape, and non-sandboxed remote code execution. One issue involved manipulation of the working directory parameter used by Cursor’s sandboxed command execution. Another involved symlink path resolution. In both cases, Cato says attacker-controlled instructions could steer the coding agent into actions that undermined the sandbox and allowed commands to run outside intended restrictions.
No active exploitation campaign has been confirmed in the available disclosure. The exposure is architectural. AI coding agents are being given access to project files, terminal operations, repositories, package managers, cloud tools, issue trackers, model context protocol integrations, and internal documentation. The environment around the model becomes as important as the model’s output.
Prompt injection is often treated as an application-layer risk: a malicious instruction causes an AI system to ignore policy, leak data, or produce unsafe content. DuneSlide shows a more direct path into system compromise. If the AI application is connected to tools with write access, shell access, or workflow authority, malicious instructions can become a route into conventional software vulnerabilities and endpoint compromise.
Developer machines are attractive targets because they often hold source code, SSH keys, API tokens, cloud credentials, local secrets, package publishing rights, signing material, and access to CI/CD systems. They may also connect to SaaS workspaces containing issue data, design documents, customer information, and production-adjacent operational detail. A compromise of a developer workstation can cross from endpoint security into software supply chain risk.
The control challenge is difficult because the productivity case for AI coding tools is strong. Organisations are under pressure to let developers use assistants that generate code, summarise repositories, automate commands, and integrate with project systems. Blocking the tools entirely may be unrealistic, while allowing them without guardrails creates a new trust layer inside engineering environments.
Governance needs to focus on permissions, not just tool approval. Organisations need to know which AI agents can run terminal commands, whether they can write outside project directories, which MCP servers and integrations are approved, whether secrets are exposed to local context, how repositories are segmented by sensitivity, and whether developer laptops are monitored for unusual command execution.
Sandboxing remains necessary, but DuneSlide shows that a sandbox has to be threat modelled around the agent as well as the application. A language model that can choose parameters, call tools, and operate on files may reach code paths that a conventional remote attacker could not normally touch.
AI developer tools are becoming part of the build environment. Their vulnerabilities, integrations, and defaults now affect the assurance of the software that enterprises ship. Engineering teams need authority, observability, and rollback controls to match the level of access these tools receive.
