The Three Feeds of Cursor's Security Fixes: Which Releases Are Safe?

The two most recently disclosed sandbox escapes in the Cursor IDE for macOS were both high severity, found by the same researcher (Danus365), and not assigned CVE numbers. Each was disclosed only as a GitHub security advisory (GHSA-p9g2-cr55-cw9c and GHSA-v4xv-rqh3-w9mc), not as a numbered vulnerability.

Many security teams track CVEs and nothing else. For those teams neither of these fixes exists: no scanner flagged them, no ticket opened, nobody upgraded. But a sandbox escape is a sandbox escape whether or not it gets a number, and both of these were fixed in public.

So a team watching only the CVE feed never learns it was exposed, and never learns the exposure ended. It keeps running a build with both escapes still in it, and nothing in its pipeline will ever say so.

The oldest version you can run safely

When a vendor fixes a security bug, every affected release up to the fixed one is still affected by the bug. So there's an oldest release that still contains every published fix, and if you're behind it you're carrying bugs the vendor already publicly fixed. We can call it the version floor. The version floor in Cursor's case is what Cursor's published metadata says is safe. It is not proof that your particular build includes the fixes.

If you let Cursor auto-update, which is the default, you always run the newest release, so you stay above the floor without ever working out where it sits. The floor matters if you pin: deliberately freeze the software at a chosen version so it can't change any further without your approval. A CI image built once, a container with a frozen toolchain, an enterprise build locked so an update can't break a thousand laptops on a Tuesday: all three can run for months with no version change at all.

Finding your version floor for Cursor means collecting information from three different places, because a fix can appear in any of them. The CVE feed carries vulnerabilities that got a public numbered ID (a CVE). Cursor's own advisory feed carries those CVEs, plus security advisories that Cursor publishes with no CVE assigned; GitHub gives each one a GHSA- ID instead. Finally, the changelog carries the rest: boundary changes that were included in an ordinary release note with no advisory at all. Each layer is more low key than the previous, and most teams only watch the first.

Cursor needs two version floors rather than one, because "Cursor" is two programs. The IDE you open, and cursor-agent, the command-line tool people wire into pipelines. Separate releases, separate advisories, separate numbers:

3.1.2 is not simply "the release after the fix". Cursor runs two release lines at once, and the fix for the virtual-environment sandbox escape was written against current code and then applied backwards to the older one:

So Cursor lists the bug as affecting every build before 3.1.2, and names no patched build at all on the main 3.x line. There is no published record of which main-line build first carried the fix, because the changelog documents no main-line release after 3.11.

The trap is that 3.11 is a higher number than 3.1.2 and an older build than 3.1.2. Any check that reads "your version is above the floor" will pass a 3.11 machine that has never seen the July 14 fix. If you are pinned anywhere on the 3.x main line, ask Cursor which main-line build carries the virtual-environment fix.

You can't compare the two version numbers: the IDE counts 1.3, 2.0, 3.1.2, and the CLI stamps a build date. Checking the IDE version tells you nothing about which CLI build you have, and the reverse.

The CLI floor comes from four advisories that carry CVE numbers. Three of them are scored 8.8, and all four clear at 2025.09.17-25b418f. Two of the four involve MCP, the Model Context Protocol, which is how an agent connects to external tools and data sources. The four are: a sensitive-file overwrite bypass (CVE-2025-61593), remote code execution through the OAuth2 path of the CLI's MCP support (CVE-2025-61591), a too-permissive CLI config that reaches code execution (CVE-2025-61592), and command injection via untrusted MCP config in the Beta channel (CVE-2025-64109).

Even here, the CVE feed alone does not automatically hand you the version floor. NVD's entries for CVE-2025-61591, CVE-2025-61592 and CVE-2025-61593 each say the issue "does not currently have a fixed release version, but there is a patch, 2025.09.17-25b418f." The build string is in the advisory prose, not in a version field a scanner can read. The IDE floor is harder still, so the rest of this post follows the IDE.

What the no-CVE fix costs you, precisely

The advisory that sets the IDE floor at 3.1.2 is GHSA-p9g2-cr55-cw9c. An agent running in the IDE's Auto-Run Sandbox mode (the desktop app's own boundary, separate from the cursor-agent CLI's auto-review) replaces the Python interpreter inside a virtual environment (a project-local copy of Python) with a wrapper script of its own. When the Microsoft Python extension later invokes that interpreter, it runs outside the sandbox, with the user's privileges. Fixed in 3.1.2.

GHSA-v4xv-rqh3-w9mc was filed the same day by the same researcher, also with no CVE. There, an agent with Docker Desktop present launches a privileged container and mounts the host filesystem to break out. It affects only builds before 3.0.0, so it doesn't move your floor. Like its sibling, it appeared in the advisory feed and nowhere else.

Reading the advisory feed instead of the CVE feed moves the IDE floor by exactly one release. A CVE-only reader already gets pulled up to 3.0, because the two DuneSlide sandbox escapes (CVE-2026-50548 and CVE-2026-50549, found by Cato AI Labs and Maor Dokhanian) carry CVE numbers. The virtual-environment escape, which has no CVE, is what moves 3.0 to 3.1.2. One version gate.

One version gate sounds small, and the error always runs the same direction: every feed you skip sets your floor too low, never too high, so you keep running an older build than you think is safe. Our own first pass read fewer feeds and put the floor at 2.0, with two more sandbox escapes sitting in the gap between 2.0 and 3.0. Both are Critical: NIST scores DuneSlide I and II at 9.8 under CVSS 3.1, and GitHub, as the CNA that issued the CVEs on Cursor's behalf, scores them 9.3 under CVSS 4.0.

The layer below that: fixes with no CVE *and* no advisory

Then there are the boundary changes that never reached any security feed at all. They appear in ordinary release notes, between feature announcements, and no scanner will ever surface them:

‍

The first four are version-gated: pin below the release and you keep the old behavior. The last two, marked *(cloud)*, are Cursor's own cloud-agent environments. No local upgrade touches them, and they're here because they're the same kind of silent, no-CVE boundary change, not because a pin fixes them.

Read each as a question about your own setup: did we change that default ourselves, or did we cross the version where Cursor changed it for us?

Nobody outside Cursor can verify these six changes

Every row in that table is Cursor's own account of what it changed. We could not test any of it, and neither can you: Cursor publishes no build archive, so the April and May releases those changes shipped in are no longer downloadable, and there is no old version left to run the new one against. On a closed fork with no build archive, an outsider cannot check a vendor's security claim at all. You take Cursor's word for those six rows, or you test the current behavior on your own machine.

Other vendors don't force this choice. Our Claude Code and Codex posts ran the vulnerable build beside the fixed one and showed the change directly, and Codex links each release note to the pull request behind it, so you can read the fix itself. Cursor links nothing and keeps nothing. (The companion to this post does run live tests, on the one Cursor surface where that's still possible.)

We caught one silent change in the act, on the CLI. Two cursor-agent builds twelve days apart, --help output diffed: the newer one had added --endpoint, which overrides the API server the agent talks to, and a plugin subcommand for installing plugin marketplaces. No advisory, no security note, twelve days. Anyone could have run that diff at the time, and nobody can run it now, because the older build is gone. The current half still checks out: cursor-agent --help lists both.

One practical note if you script against the advisory feed: read the patched_versions field rather than assuming it's populated. A few advisories resolve to no installable version at all, either fixed on Cursor's servers by date, or published with no patched version, or carrying version metadata that looks like a typo. None of them move your floor.

What to do

Take two inventories. Run the two check commands from the IDE/CLI floor table above. cursor --version does not answer the IDE question, even with the IDE installed — it only reports the CLI. Read the IDE's version out of the app bundle instead. Record the IDE and the CLI as separate assets, each with its own floor, and alert when either drops below it.

Sort those strings as versions. "3.10" is newer than "3.1.2"; alphabetical sorting says the opposite.

Watch the advisory feed. The escape that sets the IDE floor at 3.1.2 appears only as a GitHub advisory, so a CVE-only pipeline stops you at 3.0.

Audit the defaults nobody changed. Workspace Trust on, automatic tasks off, run-mode chosen deliberately. None of these are version-gated: no floor covers them and upgrading won't set them, so they're yours to check regardless of which build you run.

What this means for your risk posture

Because Cursor spreads its fixes across three feeds of decreasing visibility, a scanning method built for only one of will silently miss the other two. It’s recommended to track all three: the CVE feed, Cursor's own advisory feed, and the changelog. Where Cursor won't let you verify a claim yourself, as with its six undocumented IDE changes, treat the published record as the ceiling of what you can know, and weigh your remediation efforts accordingly: patch fast on the feeds you can verify, and audit configuration defaults on every release regardless of what any feed says.

Agentic AI and AI-driven development are moving very quickly. This means that sometimes vendors prioritize speed of innovation over more traditional security disclosure methods, which creates an expectation gap that security teams miss. This couple with the very rapid (sometimes daily) updates, makes it hard to nail down safe versions, and the floor version method can help — as long as it takes all of the available information into account. Putting the right processes in place is not necessarily hard, but does require adjusting to the reality of how differently these software platforms operate.

‍