Insights

    AI Security

    Prompt injection stopped being a content problem the moment it reached RCE

    Devence Lab

    · 2 min read

    Share
    Prompt injection stopped being a content problem the moment it reached RCE
    Photograph · Unsplash

    Disclosed flaws in developer tooling chain injected HTML to a rewritten MCP configuration to arbitrary command execution, with no further user interaction. That chain changes the severity conversation.

    Two disclosures from this cycle show the same chain, and it starts with text and ends at a shell.

    CVE-2026-30615 in Windsurf is classified zero-click: opening a Git repository that contains a malicious MCP configuration triggers code execution with no user interaction at all. Not a prompt the user accepted. Opening the folder.

    CVE-2025-54136, named MCPoison, is the more instructive one.

    Approve once, compromised later

    MCPoison exploits Cursor's approval model. Once a user approves an MCP configuration, Cursor never re-validates it. So an attacker commits a benign .cursor/rules/mcp.json to a shared repository, waits for a teammate to approve it, then swaps in the malicious payload. Every subsequent launch silently runs the attacker's commands, against an approval that was given for entirely different content.

    At CVSS 7.2 it scores lower than the zero-click flaws, and it is considerably worse in practice, because the victim did everything correctly. They reviewed a configuration and approved it. The review simply had no binding relationship to what would later execute.

    One-time approval is equivalent to no authorisation once the thing approved can be replaced without notice.

    The mental model that expired

    Prompt injection was originally filed under content safety: make the model say something it should not. Under that framing the mitigation is output filtering and the worst outcome is embarrassment.

    These chains are not that. The model is not tricked into saying anything. It is tricked into writing a configuration file, and the file is what executes. The model is a step in the chain rather than the payload — so nothing done at the output layer touches it.

    Configuration is the soft target

    Both cases turn on the same weakness: agent tooling keeps settings in files the agent can write, inside the workspace it is working in, with no integrity check between write and read. Anything that can influence the agent can influence those files, and the files are trusted absolutely at load time.

    We spent a decade learning not to let a web application rebuild its own configuration from user-supplied input. Agent tooling has reproduced the pattern in a setting where the input is a repository someone asked the agent to open.

    What closes it

    Re-validate on every configuration change, not on first install, with approval tied to a hash of the current server and tool definitions — this is exactly what Check Point recommends following MCPoison, and it is the control that would have stopped it.

    Beyond that: agent configuration should not be writable by the agent; repository-supplied configuration that executes on open should be opt-in per repository rather than honoured by default; and the read path should verify integrity against a signed baseline rather than trusting whatever is on disk.

    Sources

    1. MCP Security Vulnerabilities: Preventing Prompt Injection and Tool PoisoningPractical DevSecOps
    2. Six MCP Security Incidents Every Security Leader Should KnowUpGuard
    3. MCP Supply Chain Advisory: RCE Vulnerabilities Across the AI EcosystemOX Security

    Written by the Devence Lab research team.

    Share

    Collaborate

    We share findings with partners operating in the same constraint space.

    Get in touch