Cursor’s CurXecute Flaw Shows Why SOC Teams Must Monitor AI Plugin Behaviours

Another week, another AI-enabled development platform found to be silently executing malicious code. Cursor, a rising AI-powered code editor, recently patched a critical vulnerability that could allow full remote code execution (RCE) via a poisoned prompt. The flaw, tracked as CVE-2025-54135 and dubbed CurXecute, exploited the Model Control Protocol (MCP) plugin system used to extend Cursor’s capabilities with tools like Slack or GitHub integrations. The disclosure by Aim Security reads like a textbook case of how “smart” agentic systems can be tricked into behaving with zero oversight.

Cursor users running version 1.2 or earlier were vulnerable to this attack, which hinged on silently overwriting the ~/.cursor/mcp.json file. This allowed an attacker to hijack agent runtime behaviour, push commands to the host machine, and bypass existing security protections by abusing Cursor’s default trust model.

Tactical or technical breakdown

The vulnerability stems from how Cursor handles MCP server definitions. These are JSON configurations that tell Cursor how to interact with external tools (e.g. Slack, GitHub, etc.). The core flaw is that any new MCP server added to this config file would auto-run without user confirmation. Cursor’s agent, running with developer-level privileges, would then treat any interaction with these tools as trusted.

Here’s how it plays out:

1. The user adds a Slack MCP server via Cursor’s UI.
2. An attacker sends a malicious Slack message to a public channel.
3. The user instructs Cursor’s AI agent to summarise Slack messages.
4. The agent hits the poisoned message, which silently injects commands.
5. Those commands are executed immediately with the user’s privileges.

Because of how Cursor’s denylist was implemented, even rejected or malformed edits would still trigger the execution. Attackers could obfuscate payloads using common shell tricks like Base64 or quoted commands ("e"cho bypass). HiddenLayer researchers demonstrated a similar exploit by embedding prompt injections inside GitHub README files. These could trigger data exfiltration—stealing SSH keys or API tokens—by chaining benign-sounding tools like read_file and create_diagram.

What this means for defenders (blue team insight)

This is not just an AI problem. This is a visibility and trust boundary failure.

From a SOC perspective, these agent-based tools are black boxes unless you’re actively collecting telemetry. Here’s what defenders should focus on:

• Monitor config file modifications: The ~/.cursor/mcp.json file should be tracked for unauthorised changes. Any insertions involving new tools or server addresses must be flagged.
• Log AI agent behaviours: SOCs should push for detailed audit logs from these tools. Knowing what prompts were issued, which commands were executed, and what external interactions occurred is now essential.
• Detect obfuscated shell commands: Implement detection for Base64-decoded payloads, suspicious CLI combinations (curl, grep, chmod), and especially requests made to webhook.site or pastebin-like domains.
• Kill default allow behaviours: If a platform offers auto-run modes, it must be opt-in only. The denylist approach used here failed because attackers could easily bypass it.
• Tag AI interactions with context: If your users are running AI tools that fetch code or messages externally (e.g. summarising Slack threads), that action needs tagging, review, and logging just like a download from an unknown Git repo.

Finally, this incident reminds us that agentic AI tools don’t follow the traditional software trust model. Their logic flows are contextual, not static. This means defenders must shift from static signature-based detection to dynamic behavioural analysis, even for so-called “developer tools”.

Final thoughts

Cursor’s patch in version 1.3 removes the denylist approach and replaces it with an allowlist for auto-run tools. That’s a step in the right direction—but it doesn’t solve the deeper issue: AI agents are now reaching into external systems, interpreting natural language, and running code with little to no oversight.

For blue teams, this means you’re no longer just defending endpoints and servers. You’re defending a conversation between a user and an agent that might lead to code execution, data exfiltration, or credential compromise.

Agent-based tools need guardrails. Not just better prompts or filters—but runtime observability, execution control, and forensic-ready logging. Because when the next prompt injection hits, it won’t be visible in your EDR alerts—it’ll be buried in a Slack channel or a GitHub README.