Findings of about two weeks of investigation

Cursor, the U.S. maker of an AI coding tool, said on its official X account on Nov. 13 (10:13:26 a.m. Nov. 14 Japan time) that it had published an update on its investigation into a security breach that occurred in late October on its official blog. The blog post gives a detailed account of what happened and the steps the company took.

We’ve published an update on our recent security incident. See a detailed overview of what happened and our remediation steps here: https://t.co/2lf6lRJPlL

On Oct. 29, Cursor disclosed that a tampered version of Anthropic's "Claude Code" extension had been distributed on its extension store (initial report). According to the blog post dated Nov. 13, the investigation over the roughly two weeks since then pieced together the overall picture of the attack and its impact. The vast majority of users were not affected, and the company said it contacted each affected user directly with the details that apply to them. Cursor said the breach involved data it stored and shared, credentials it issued and systems it operates.

It began with a key issued to vendor Fireworks

According to the blog, the attack began with an access key Cursor had issued to its vendor Fireworks. The key was exposed on Fireworks' side, and the attacker used it to copy data from a read-only storage bucket Cursor used to share data with the vendor. The bucket held a limited set of coding agent traces, mostly from 2025, from usage not in Privacy Mode that Cursor was permitted to use for model training.

A small number of the traces contained credentials that had not been redacted. Less than 0.01% of customers had API credentials exposed. Starting from those credentials, the attacker got into some of the business tools (SaaS) Cursor uses. From there, the attacker accessed some archived source code repositories not used in production (some containing business contact information), some support data and email conversations, product usage metrics and contact details, summaries of some agent conversations, and some credentials users had sent to the support team.

Among users not using Privacy Mode, fewer than 0.05% had their traces exposed. Cursor said it identified those users and notified each of them directly, and that users who did not receive a notification were not in the traces.

The tampered extension came through the same path

Cursor's monitoring systems detected the unauthorized activity, and the company deactivated the vendor's key and began its response. It said it revoked and rotated credentials, hunted for further unauthorized access and cut it off as it was found. As a precaution, it temporarily disabled internal and product services well beyond what the evidence required, which temporarily disrupted some Cursor features.

On Oct. 29, using a credential for an internal system obtained from the exposed data, the attacker placed a tampered Claude Code extension directly on the cache used to serve Cursor's extension store. The blog said the tampered version was not published by Anthropic and was not a vulnerability in Anthropic's product. Open VSX, the source of the store, never had the malicious code. Up to 5,000 users who requested specific cached versions on Oct. 29 may have received the tampered version, which was available for about 11 hours before it was removed.

The blog lists two version numbers for the tampered extension: 2.1.312 and 2.1.313. It asked users who installed or updated to either one from Cursor's store during that period to follow the steps in its October notice. Uninstalling the extension alone may not be enough, the company said.

No attacker activity seen after Nov. 1

Cursor said it believes the breach is contained. The last attacker activity it saw was on Nov. 1, and that activity was blocked, the company said. It said it continues to monitor its systems and will contact users directly if it identifies new information that affects them.

The blog listed as unaffected prompts and code sent in Privacy Mode, data and traffic being sent now, and the production systems that run Cursor. The app and its official updates, and the code shipped to users' devices and to the cloud, were also not affected; the company said it ships the app from a separate code hosting system the attacker never accessed, and that no release signing keys were exposed. It said other extensions on the store, plugins on the Cursor Marketplace, customer code repositories, other products such as Cloud Agents for customer teams, and active inference requests were not affected either.

Inference moved off the vendor, credentials rotated across the board

According to the blog, Cursor moved all inference (the processing in which AI produces answers) traffic off Fireworks, deactivated the key it had issued to the vendor and cut off its access to the shared data. It rotated every exposed credential it found, highest risk first, and as a precaution rotated all credentials across its internal systems, even where there was no evidence of exposure.

It also validated that the other extensions on the store were authentic and rebuilt the store, and expanded restrictions at its service providers, where possible, so credentials cannot be used outside their intended location. It added secret scanning and protections across all its code repositories, and redeployed all production systems and services as a precaution. It said it engaged external forensics experts and contacted everyone affected.

Cursor apologized in the blog to those affected and said it will update the post if anything important changes. The blog does not say how the key was exposed on Fireworks' side, or how many support records or credentials were exposed.