SpaceX Owns Cursor Now, and It Still Has an Unpatched Security Hole

SpaceX closed its $60 billion Cursor acquisition with no new data policy for existing users, while a rival AI lab's disclosed file-write vulnerability in Cursor remains unpatched. Here is what is confirmed, what isn't, and what to do.

Posted Aug 19, 2026

A rocket icon docking into a text-cursor icon with an unlocked padlock badge above the connection point

By Nakshatra Ranjan Saha (OCEANOFANYTHING)

views 10 min read

SpaceX Owns Cursor Now, and It Still Has an Unpatched Security Hole

Quick answer

SpaceX closed its $60 billion all-stock acquisition of Anysphere, the company behind the Cursor code editor, on August 14, 2026. As of this writing, neither SpaceX nor Cursor has published a data handling policy specific to the acquisition that tells existing paid users what changes for their code. Separately, Z.ai released its GLM-5.3 model the same day and said the model had found a “potentially serious” vulnerability in Cursor involving arbitrary file writes. Cursor has confirmed it is working on a fix, but no patch, advisory, or CVE for that finding had been published as of August 20, 2026. If you keep client code in Cursor, the single most useful thing to do this week is open Settings, go to Privacy and Data, and confirm your Privacy Mode setting yourself, because that toggle, not the change in ownership, is what currently controls whether your code can be used to train any model.

What actually happened with the acquisition

The deal took shape over months. SpaceX’s own account said as far back as June 16, 2026 that xAI had already been jointly training a new coding model with Cursor for several months. The acquisition formally closed on August 14, 2026, converting Anysphere’s outstanding shares into roughly 389 million shares of SpaceX Class A stock, an all-stock deal valued at about $60 billion. Cursor became a wholly owned subsidiary, folded into a new SpaceXAI division alongside xAI, and it is widely described as the largest startup acquisition on record.

Anysphere had grown fast enough to justify the price on paper: reports put its annualized revenue at roughly $4 billion with more than 50,000 enterprise customers by the time the deal closed, up from a $29.3 billion Series D valuation a year earlier, meaning SpaceX paid something like 15 times revenue.

What Cursor and SpaceX have said, and have not said

Cursor’s blog post about the closing focused on compute access, the Colossus supercomputer, and joining SpaceXAI to build tools like Grok Build and Grok Bot. It did not address data handling for existing paid customers, and no separate statement doing so has surfaced since.

Cursor’s official privacy documentation, still live at cursor.com/data-use and cursor.com/help/security-and-privacy/privacy, has not been rewritten around the acquisition. It already references SpaceXAI in passing when describing retention arrangements, so the corporate integration is real, but the policy itself is unchanged: with Privacy Mode off, Cursor says it may use and store codebase data, prompts, editor actions, and code snippets to improve its AI features and train models; with Privacy Mode on, none of that is used for training, for any model, including Grok.

What has changed is who sits above that policy. SpaceX is now the parent company and, in principle, could rewrite Cursor’s data terms later. Neither company has made a public commitment about what happens to existing paid customers’ code if that happens, which is the accurate way to describe the current gap: not a confirmed bad outcome, but an absence of any stated commitment.

One more change predates the closing: in late June, Cursor added Grok 4.5, trained in part on Cursor developer-session data, as a selectable model. That followed the same Privacy Mode rule that governs every model Cursor offers, not a special carve-out for Grok, so sessions were only eligible if Privacy Mode was off. Some commentary has overstated this into a claim that Cursor secretly changed what Privacy Mode does. It did not, but it is a good reason to check your own setting rather than assume you remember it correctly.

The vulnerability: what is confirmed and what isn’t

On August 14, 2026, the same day the SpaceX deal closed, Chinese AI lab Z.ai released GLM-5.3 and said the model had found a “potentially serious vulnerability” in Cursor during a reverse-engineering exercise. A Z.ai developer advocate described it as an architectural risk in Cursor’s Electron-and-Rust codebase that could allow arbitrary file writes, meaning a working exploit could let an attacker write files outside the boundaries the editor’s sandbox is supposed to enforce. Z.ai says it disclosed the finding to Cursor privately rather than publishing exploit details, and that Cursor’s team is working with it on a fix, with more information promised “once users are protected.”

What is not confirmed matters just as much. There is no published CVE for this finding, no security advisory from Cursor referencing it, and no independent technical write-up of the exact exploit path beyond the general “arbitrary file write” description. Every report traces back to Z.ai’s own release material and the press coverage repeating it, not to a neutral third party or Cursor’s own advisory feed. That does not make the claim false, GLM-5.3’s broader jump on benchmarks like CyberGym and ExploitBench is real, but the mechanism and severity of this one finding should be treated as a vendor’s claim until Cursor publishes something in its own name.

Worth naming plainly rather than dramatizing: Z.ai competes with the companies now inside Cursor’s ownership structure, and its Chinese lab surfaced this flaw in a code editor newly owned by a US aerospace and defense contractor, as part of announcing its own model’s security chops. Both things can be true at once, the vulnerability can be real and the disclosure can also be useful marketing. Neither fact should change your actual response, which has nothing to do with who found it.

As of August 20, 2026, Cursor has not published a patch, changelog entry, or advisory naming this vulnerability, consistent with Z.ai’s statement that a fix is still in progress rather than a sign the report was dismissed. It is worth checking back, since Cursor has previously shipped fixes as ordinary version updates before writing up an advisory, if it writes one up at all.

What this actually means if you have client code in Cursor

Two separate things are true, and they call for different responses.

The ownership change is a business risk, not an active technical one. Nothing about SpaceX owning Cursor changes what already happened to code already sent to a model provider under whatever Privacy Mode setting you had at the time. The realistic exposure is forward-looking: terms could change later, product direction could shift further toward Grok integration in ways that affect model choice or pricing, or a future policy rewrite could loosen data handling without much warning. That is worth planning around, not panicking about today.

The vulnerability is a live but unresolved technical risk, and unpatched does not mean actively exploited. An arbitrary-file-write flaw matters because, if a working exploit exists, it could let a malicious file, prompt injection, or extension trigger writes outside the sandbox. But a privately disclosed, being-fixed vulnerability with no public proof of concept and no CVE sits in a different risk tier than an actively exploited zero-day. Cursor’s own record this year cuts both ways: a git-related remote code execution bug was reportedly fixed within about three days of a private report in July, while a separate Chromium-inheritance issue took roughly seven months to close. That inconsistency, more than this one bug, is the more useful signal for how much trust to extend to any AI coding editor, Cursor included.

What to actually do this week

Update Cursor to the latest version before anything else. Whatever the fix turns out to be, it will ship as a normal version update, and staying current is the only real lever you have over a vulnerability whose details are still under embargo.

Open Settings, go to Privacy and Data, and confirm whether Privacy Mode is actually on rather than assuming it matches what you set months ago. If you handle client code under any confidentiality obligation, it should be on, and if you run a team, check whether it is enforced at the workspace level instead of left to each developer. Read Cursor’s own data-use and privacy pages directly rather than relying on secondhand summaries, this one included, since policy pages can change without an announcement.

If you are doing genuinely sensitive work right now, anything under an NDA, healthcare or financial data, or unreleased product code, it is reasonable to hold off on pointing Cursor’s agent mode at that specific codebase until a fix or advisory ships. Not because exploitation is confirmed, but because agent mode’s broader file system access is exactly the surface an arbitrary-file-write bug matters most for. Ordinary autocomplete-style usage carries meaningfully less exposure than an unattended agent with write access to your project.

None of this requires migrating off Cursor. A full pause makes sense only if the ownership uncertainty alone is disqualifying against your own compliance requirements, a business call rather than a security one. If you are weighing that anyway, an open-source, self-hostable option like OpenCode removes the single-vendor data question entirely, at the cost of more setup work. If the comparison you actually care about is which coding agent to use day to day, this comparison of GitHub Copilot, Claude Code, and OpenCode lays out how the mainstream options stack up. And if cost rather than ownership is the real constraint, running an agentic workflow through Opencode Zen covers a cheaper way to get comparable functionality without leaning on any single vendor’s defaults.

Frequently asked questions

Has the Cursor vulnerability GLM-5.3 found been patched? Not as of August 20, 2026. Z.ai says Cursor is working on a fix and will share more once users are protected, but no patch, advisory, or CVE has been published for this finding. Update to the latest Cursor release and check back on Cursor’s own advisory feed, since a fix could land quietly as a routine version bump.

Does SpaceX now own the code I write in Cursor? No. SpaceX owns Anysphere, the company, and therefore Cursor’s product and infrastructure, not your code by virtue of the acquisition. What matters is Cursor’s data handling terms, which have not been rewritten specifically because of the acquisition as of this writing.

Is my code being used to train Grok? Only if Privacy Mode is off on your account, per Cursor’s own documentation, which applies that rule to every model it offers, not a special exception for Grok. Check Settings > Privacy and Data to see your current status.

Should I stop using Cursor for client work? For most day-to-day work, no, based on what is currently confirmed. For specific, sensitive codebases under an NDA or regulatory requirement, it is reasonable to hold off on agent-mode access to that codebase until a fix ships, while continuing normal use elsewhere.

Is the vulnerability being actively exploited right now? There is no public evidence of that. The report so far is a private disclosure from Z.ai with no published proof-of-concept code, a materially lower-urgency situation than a confirmed in-the-wild zero-day, though it still warrants keeping Cursor updated.

Sources

cybersecurity, Tech News, Developer Platforms

This post is licensed under CC BY 4.0 by the author.