A pattern, not a single bug
Over the past year, a specific class of vulnerability has shown up in AI coding tools often enough to stop looking like a one-off and start looking like a structural problem. The shape is consistent: an attacker plants instructions somewhere an AI agent will read on your behalf — a Slack message, a webpage, an issue tracker comment — and the agent, trusting that content the same way it trusts your actual prompt, follows the hidden instructions instead. That's prompt injection, and in coding agents specifically, it keeps landing on remote code execution.
Cursor's history with this pattern is instructive precisely because it isn't a single incident. "CurXecute," disclosed in mid-2025, showed that a planted Slack message could rewrite Cursor's MCP configuration file and get commands executed — even if the user explicitly rejected the suggested change. Cursor patched it. Then "MCPoison" showed a related path through project-specific configuration approval. Cursor patched that too, adding a requirement that any change to an MCP configuration — even something as small as adding a whitespace character — triggers a mandatory approval prompt.
Then, disclosed publicly this year, "DuneSlide" found yet another way through: a poisoned prompt from a connected service combined with a bypass of the command whitelist mechanism, again resulting in commands executing without the user's actual intent. Each fix closed one specific door. Each new disclosure found a different one.
Why this keeps happening
The underlying tension is architectural, not a matter of any one team being careless. Coding agents are useful precisely because they run with real, meaningful privileges — filesystem access, shell execution, the ability to modify configuration and install dependencies. That's the entire value proposition. But those same agents are designed to process untrusted external content as part of normal operation: a Slack channel they're asked to summarize, a webpage they're asked to check, an MCP server response they're asked to act on.
Put those two things together and you get a fundamental problem: the agent can't reliably distinguish "instructions from the person I'm working for" from "text I happened to encounter while doing my job." When that boundary fails, developer-level privileges become available to whoever controlled the content the agent was reading.
This isn't just a Cursor problem
It would be a mistake to read this as one tool having a rough year. Similar prompt-injection-to-RCE patterns have been disclosed across the broader coding agent ecosystem, and the vibe coding security research covered elsewhere this year backs up the same underlying story from a different angle: AI-generated and AI-driven workflows are introducing meaningfully more security findings than equivalent human-driven work, not because any single model is unusually bad, but because the entire category of tool operates on a trust model that's still catching up to how much autonomy these tools now have.
What this means if you're using these tools
A few practical habits are worth adopting regardless of which coding agent you use:
Treat any MCP server connected to external content — Slack, email, issue trackers, the open web — as untrusted input, the same way you'd treat user-submitted form data on a website.
Review configuration-change prompts carefully, especially ones you didn't explicitly ask for. If your agent suggests editing its own MCP config or permissions, that's exactly the moment these exploits target.
Keep your tools updated, and actually read the changelog for security-relevant fixes rather than just clicking through the update. This entire category of vulnerability gets patched reactively, one disclosure at a time.
Scope agent permissions as narrowly as the task allows. An agent that only needs to read a repository doesn't need shell execution enabled by default.
The tools aren't going anywhere, and the productivity gains are real. But "my coding agent has developer-level privileges and reads untrusted content as part of its normal job" is a genuinely new attack surface, and it deserves the same scrutiny you'd give any other privileged system that processes input you don't control.
