Cursor is a full AI-native editor, so people ship serious, substantial apps with it - not just prototypes. That means substantial surface area too. We review Cursor-built apps for access-control gaps, exposed secrets, and agent-specific risks, then fix what we find.
Run a free 30-second scan Book an auditCursor (by Anysphere) is a VS Code fork with AI chat, inline edits, a multi-file Agent Mode, terminal command execution, and full codebase indexing. Unlike one-click app builders that provision a whole stack for non-developers, Cursor is built for people who already code and choose their own backend, database, and hosting - Cursor itself claims use across a majority of Fortune 500 engineering teams. That flexibility is exactly why the security of what gets built in it varies so much: nothing is provisioned for you by default, including the checks that keep an app safe.
These are the specific, recurring patterns we see when we audit apps built in Cursor - not generic AI-code warnings.
Change an ID or parameter in a request - an order number, a user ID, an invoice - and you can read or edit someone else's record, because the endpoint never checks that the requester actually owns that object.
We fix it by adding server-side ownership checks on every object-returning route, not just the ones that "look" sensitive.
A reversed conditional - an if (!isAdmin) that should read if (isAdmin), or a check that fires on the wrong branch - quietly lets unauthenticated users through a gate that looks like it's working in a demo.
We fix it with auth-boundary tests and established middleware instead of hand-rolled conditionals.
The UI hides an admin button or a locked feature, but the API behind it has no server-side check - anyone who calls the endpoint directly, bypassing the interface entirely, gets full access.
We fix it by authorizing every request at the API layer, treating the UI as decoration, not a gate.
API keys and credentials get typed straight into source rather than an env var - and once committed, they're in your git history even after you "remove" them. This lines up with broader industry data showing AI-assisted repositories leak secrets at a meaningfully higher rate than human-only ones.
We fix it by moving secrets to a manager, rotating anything exposed, and adding pre-commit secret scanning.
AI coding tools sometimes suggest a package name that doesn't exist. Attackers register those exact names on public registries, so the next AI suggestion - or a teammate typing it from memory - pulls down malware instead of a library.
We fix it by verifying every dependency actually exists before it ships, reviewing the lockfile, and allowlisting registries.
This is about Cursor the product, not the code it writes for you. Cursor holds SOC 2 Type II (available on request) and offers Privacy Mode with no training on your code, plus zero-data-retention agreements with its model providers. Enterprise/Business tiers add SSO, SCIM, audit logs, and customer-managed keys. Two things matter for anyone using its agent features on a real codebase: Workspace Trust is disabled by default, and requests still transit Cursor's own backend regardless of which model answers them. Neither of those is a flaw in your app - but both shape how you should run the tool.
| Item | Status |
|---|---|
| HIPAA / BAA | No BAA offered on any tier as of early 2026 - not suitable for direct PHI handling without compensating controls. |
| SOC 2 Type II | Available on request via Cursor's trust center - attests to Cursor's own systems, not the app you built in it. |
| Codebase indexing | Sends code chunks (including comments, fixtures, seed data) to Cursor's servers for embeddings - PHI/PII/secrets in a repo can leave the machine even in Privacy Mode. |
These are flaws in the editor/agent, distinct from anything in the apps it generates - relevant if you run Cursor's agent features against a real codebase.
| CVE | Severity | What it did |
|---|---|---|
| CVE-2025-54135 "CurXecute" | CVSS 8.5–8.6 | Indirect prompt injection (e.g. via a connected Slack MCP server) silently rewrote Cursor's global MCP config to execute an injected command with no confirmation. Fixed in Cursor 1.3. |
| CVE-2025-54136 "MCPoison" | CVSS 7.2 | Once you approved an MCP config once, Cursor auto-trusted later edits to it - letting an attacker swap in a malicious command after the fact. Fixed in Cursor 1.3. |
| Workspace Trust / autorun flaw | - | Workspace Trust off by default meant a malicious repo's .vscode/tasks.json could auto-execute on open; researchers found four ways to bypass the command denylist. Cursor moved to an allowlist model in 1.3. |
| "DuneSlide" (CVE-2026-50548 / -50549) | CVSS 9.8 | Two zero-click prompt-injection-to-RCE flaws - no user interaction needed, triggered via a connected MCP server or a poisoned web-search result. Fixed in Cursor 3.0. |
| "NomShub" (CVE-2026-22708) | - | Hidden instructions in a project README triggered a sandbox escape via shell builtins, with persistence through ~/.zshenv - worst impact on macOS. Patched. |
Cursor is a powerful, professional-grade editor, but the AI-generated portions carry the same recurring gaps we see across agentic tools - broken access control, frontend-only checks, and exposed secrets. Its agent features add prompt-injection considerations on top. A review makes it production-safe.
Treat any untrusted repository content (READMEs, PRs, MCP tool responses) as a potential injection vector, keep Workspace Trust intentional rather than left at its off-by-default setting, and keep Cursor updated - several of its disclosed CVEs were prompt-injection-to-RCE chains.
Cursor does not offer a BAA on any tier as of early 2026, and codebase indexing can send code chunks to its servers even with Privacy Mode on. SOC 2 Type II is not a HIPAA substitute. Treat it as unsuitable for direct PHI without compensating controls.
IDOR and broken object-level authorization - an endpoint that returns or edits a record based on an ID in the request without checking the requester actually owns it. It showed up in roughly 43% of a sampled scan of Cursor-built apps.
The initial scan is free and takes about 30 seconds. A full audit starts at and any fixes we recommend are quoted separately based on what we actually find in your app.
Free 30-second scan, then a clear list of what needs fixing before real users touch it.
Run a free 30-second scan