Cursor has spent the last year bolting AI agents onto every stage of the coding workflow: Bugbot reviews pull requests, Background Agents run tasks unattended, and the Model Context Protocol (MCP) lets the editor call out to Jira, Slack, databases, and internal APIs. Anysphere, the company behind Cursor, markets this stack as a meaningful step toward catching bugs before merge. It is also, provably, a new attack surface. In 2025, researchers disclosed two separate exploit chains — nicknamed CurXecute and MCPoison — that turned Cursor's own agent permissions into remote code execution paths. Developers searching for "cursor ai security features" are usually trying to answer one question: can an AI pair programmer actually replace a security scanner, or does it just add a fast, confident-sounding layer on top of the same blind spots? The honest answer is that Cursor's agents are useful reviewers and a genuinely novel risk category at the same time.
Does Cursor's Bugbot catch security vulnerabilities?
Bugbot catches some security bugs, but it was built as a code-review agent, not a security scanner, and its coverage reflects that. Launched in June 2025 and priced around $40 per active user per month for teams, Bugbot runs automatically on GitHub and GitLab pull requests, leaves inline comments, and can one-click generate a fix commit. It is genuinely good at the class of bug a senior engineer would catch in review: off-by-one errors, unhandled null cases, a hardcoded API key dropped into a diff, or an obviously unsanitized string headed into a query. What it does not do is dependency vulnerability matching against the NVD or OSV databases, license compliance checks, or infrastructure-as-code misconfiguration scanning — the bread-and-butter work of an SCA or CSPM tool. Bugbot's model only sees the diff and the files it touches; it has no persistent view of your dependency graph, your runtime environment, or which of the thousand CVEs in your lockfile are actually exploitable in your codebase.
What is CurXecute and why does it matter for AI coding agents?
CurXecute is a prompt-injection-to-remote-code-execution chain that researchers at Aim Security disclosed in mid-2025, and it matters because it shows AI agents can be hijacked through the exact data sources they're designed to read. The attack works by planting malicious instructions inside content Cursor's agent is likely to ingest through an MCP connection — a Jira ticket description, a Slack message, a scraped web page. When the agent summarizes or acts on that content, the injected instructions get interpreted as commands, and because Cursor's agent mode can execute shell commands and edit files with developer-level permissions, the result is code execution on the developer's machine without a single line of malicious code ever touching the actual repository. Traditional static analysis tools have no equivalent failure mode to look for here, because the vulnerability isn't in the code being scanned — it's in the trust boundary between the agent and every external system it's connected to.
What is MCPoison and how did it exploit Cursor's approval model?
MCPoison, disclosed by Check Point Research and tracked as CVE-2025-54136, exploited the fact that Cursor cached trust decisions by the name of an MCP configuration rather than its contents. Once a developer approved an .cursor/mcp.json entry — say, a database connector or internal tool — Cursor would silently trust any future edits to that same file without re-prompting, as long as the entry's name stayed the same. An attacker with write access to a shared repository (a compromised contributor account, a malicious pull request, a poisoned fork) could swap the command a trusted MCP entry actually ran, and it would execute the next time any teammate opened the project — no approval dialog, no warning. Anysphere patched the caching behavior in Cursor 1.3, but the underlying lesson holds beyond this one CVE: agent permission models that were designed for convenience, not for a multi-contributor threat model, will keep producing this exact bug class in different forms.
Can Cursor generate an SBOM or trace whether a flagged CVE is reachable?
No — Cursor has no SBOM generation and no reachability analysis, because it isn't built to model your dependency tree at all. Ask Bugbot or Cursor's chat agent "is CVE-2024-XXXX in our lodash version actually exploitable in this service," and you'll get a plausible-sounding answer synthesized from the code in context, not a verified call-graph trace showing whether the vulnerable function is reachable from an entry point. That gap matters more than it sounds: the average mid-sized codebase carries hundreds of open-source dependencies and thousands of transitive ones, and industry data consistently shows that fewer than 15% of known vulnerabilities in a typical dependency tree are actually reachable from application code. Without a real SBOM and a call graph to check against, every CVE an AI agent flags is a guess dressed up as an assessment, and every one it misses is a guess that happened to be wrong in the other direction.
Does Cursor's AI agent auto-fix vulnerabilities safely?
Cursor's agents can generate a fix commit, but "safely" depends entirely on whether anything verifies the fix before it ships, and today that verification step is manual. Background Agents and Bugbot's one-click fix will produce a patch — bump a dependency version, add input validation, escape a string — and open it as a commit or PR comment. Nothing in that pipeline confirms the patch doesn't break a downstream caller, satisfies the actual CVE advisory's remediation guidance, or gets re-tested against the exploit path that made the finding real in the first place. Teams that have wired Bugbot's suggestions straight into auto-merge have reported the same failure mode security teams saw with early autofix tooling from Dependabot and Snyk a few years earlier: a plausible-looking patch that resolves the linter warning while leaving the actual vulnerable code path untouched, because the fix was generated from pattern-matching, not from proof.
How Safeguard Helps
Safeguard treats an AI agent's suggestion as a hypothesis, not a verdict — which is the gap Cursor's tooling leaves open. Our reachability analysis builds a real call graph for your codebase and its dependencies, so a flagged CVE gets checked against whether your code can actually reach the vulnerable function before it ever reaches an engineer's queue, cutting the noise that makes teams tune out AI-generated findings. Griffin AI, Safeguard's own agent, ingests or generates SBOMs across your services and correlates them continuously against NVD, OSV, and vendor advisories, giving you the persistent dependency-graph context that Cursor's per-diff view was never built to hold. When a finding is confirmed reachable, Safeguard opens an auto-fix PR that's been validated against the actual exploit path, not just pattern-matched against the CVE description — closing the loop that CurXecute and MCPoison exposed as missing from agent-driven development.