CurXecute Prompt-Injection Flaw in Cursor IDE Enables Remote Code Execution

Cursor IDE’s CurXecute flaw lets malicious prompts escalate to remote code execution; Pi-hole donor emails leaked via GiveWP plugin misconfiguration. Patches released.
CurXecute Prompt-Injection Flaw in Cursor IDE Enables Remote Code Execution
Table of Contents
    Add a header to begin generating the table of contents

    Two separate security incidents surfaced this month, one striking at AI-assisted developer tooling and the other at an open-source funding front: a prompt-injection vulnerability in the Cursor IDE dubbed CurXecute can give attackers full code execution with developer privileges, while the Pi-hole project disclosed that donor names and emails leaked due to a flaw in the GiveWP WordPress plugin.

    CurXecute in Cursor IDE lets untrusted prompts hijack AI agent and execute commands as the user

    Researchers at Aim Security uncovered a vulnerability they named CurXecute in nearly all versions of the AI-powered Cursor integrated development environment. Tracked as CVE-2025-54135, the flaw resides in the way Cursor’s AI agents consume external data via the Model Context Protocol (MCP). MCP extends an agent’s reach by connecting it to external services—Slack, GitHub, databases—and feeding their content into the agent’s decision-making. That power, the researchers warn, becomes a liability when untrusted content carries malicious instructions.

    “MCP turns a local agent into a Swiss-army knife by letting it spin up arbitrary servers—Slack, GitHub, databases—and call their tools from natural language,” Aim Security noted, adding that any third-party MCP server processing external content (issue trackers, support inboxes, even search results) becomes a viable attack surface.

    The attack works via prompt injection: an adversary posts a crafted message on a connected MCP endpoint (for example, a public Slack channel). When a developer asks the agent to summarize or process that channel, the injected payload silently modifies the agent’s configuration by writing to the ~/.cursor/mcp.json file. Critically, Cursor does not require user confirmation for new entries to that configuration. Even rejected suggested edits can trigger execution, meaning the malicious payload—commonly a shell—lands on disk and escalates immediately.

    That escalation hands the attacker the agent’s session and privileges, enabling remote code execution under the developer’s identity. Aim Security’s report highlights the severity: a single poisoned document can transform the AI assistant into a local shell, opening paths to ransomware, data theft, unintended code manipulation through hallucination, or supply-chain–style sloppiness (e.g., typosquatting or corrupting project outputs).

    The researchers produced a proof-of-concept demonstration showing how easy it is to weaponize this vector and how the agent’s trust in external content allows the payload to persist and execute with little visibility.

    Cursor’s development team received the private disclosure on July 7, 2025. A patch was merged the next day, and on July 29, Cursor version 1.3 shipped with the CurXecute fix along with other improvements. The official advisory assigns CVE-2025-54135 a medium-severity score of 8.6.

    Users of Cursor are urged to upgrade immediately to the latest version to eliminate the known attack vector and reduce risk from compromised MCP sources.

    Pi-hole donor leak underscores risks of embedded third-party components in funding flows

    In a separate incident, Pi-hole, the widely deployed network-level ad blocker, disclosed that donor names and email addresses were exposed due to a security flaw in the GiveWP WordPress donation plugin used on its contribution page. The issue came to light after donors reported receiving suspicious emails at donation-only addresses on July 28.

    A post-mortem published by Pi-hole explained that the plugin inadvertently exposed donor metadata in the page source. No authentication was required to view the data, meaning anyone who viewed the HTML could see names and email addresses. The breach affected supporters who used the form to fund development; while Pi-hole did not specify the exact count, the breach notification service “Have I Been Pwned” recorded nearly 30,000 impacted donors, with 73% of those records already known to its database.

    Financial data was not exposed. Payment processing—credit card and similar details—was handled separately through Stripe and PayPal. Pi-hole emphasized that its core software remains unaffected and that installations do not require action.

    “We take full responsibility for the software we deploy. We placed our trust in a widely-used plugin, and that trust was broken,” Pi-hole wrote, acknowledging the exposure and apologizing to affected donors.

    GiveWP released a patch within hours of the vulnerability being reported, but Pi-hole criticized the delay in communication—about 17.5 hours—and felt the initial response underappreciated the risk to donor identity visibility. Pi-hole has accepted accountability and noted potential reputational damage even as it framed the vulnerability as previously unforeseeable.

    Dual lessons for enterprise and open-source operators

    Both incidents illustrate evolving trust breakdowns in modern tooling. Cursor’s CurXecute shows how powerful AI assistant integrations, if not carefully sandboxed or validated, can be hijacked via prompt manipulation to gain execution control. Pi-hole’s donor leak reinforces that even non-core funding flows can leak identity data when third-party components expose internal state without proper access constraints.

    Enterprises relying on AI-augmented development environments should audit connected agent frameworks and enforce strict vetting or isolation of external context sources. Open-source and donation-funded projects must evaluate embedded plugins for unintended data exposure and ensure rapid, transparent communication when flaws surface.

    Related Posts