Breaches

Follow-up: Fireworks key let attackers breach Cursor, plant extension

Cursor confirms a key leaked by partner Fireworks and secrets in old agent traces let attackers breach it and plant a backdoored Claude Code extension.

Padlock graphic with the headline Leaked partner key led to Cursor breach

Cursor has now admitted that its own systems were breached and that this is how attackers planted a backdoored Claude Code extension in its marketplace on 29 October. The way in was a Cursor-issued key leaked by inference partner Fireworks, then secrets left lying in old agent logs.

What happened

This is a follow-up. When the tampered Claude Code extension first appeared in Cursor’s VS Code extension marketplace at the end of October, the public picture was narrow: two rogue builds, an 11-hour window and an SSH backdoor. On 13 November 2026 Cursor published the results of a two-week investigation, and it changes the story. The poisoned extension was the visible end of a breach that started at a supplier and moved through data Cursor itself had stored.

By Cursor’s account, an attacker got hold of an access key that Cursor had given to Fireworks AI, its third-party training and inference provider. Cursor says Fireworks exposed the key. It opened a read-only storage bucket the two companies used to share data. Inside were agent session logs, largely dating from 2025, drawn from non-Privacy Mode use that Cursor’s terms let it train on. A small number still carried credentials nobody had redacted.

The attacker used those secrets to reach a number of software-as-a-service tools inside Cursor. From there they took archived non-production source repositories, some of which held business contact details. They also took limited customer support records and email threads, product usage metrics, summaries of some agent conversations, and credentials that customers had sent to Cursor’s support team. One stolen credential gave write access to the cache behind the extension marketplace. On 29 October the attacker used it to drop rogue Claude Code builds 2.1.312 and 2.1.313 straight onto that cache.

We covered Fireworks’ own breach on 10 November. What is new is Cursor confirming it was a downstream victim.

The technical picture

The chain has four links, and each one is a familiar weakness. First, a credential issued to a partner, which the issuing company controlled but did not hold. Second, a data store shared with that partner that held more than it should, because historical telemetry is where secrets accumulate. Developers paste tokens into prompts and tools print environment variables; unscrubbed, the archive becomes an accidental credential store.

Third, internal SaaS tools that accepted those credentials from wherever the attacker happened to be. Cursor’s own fixes point here: it says it has widened network access restrictions with service providers so that a stolen credential cannot be used outside its intended location. Fourth, a distribution cache that could be written to without the upstream registry knowing. Cursor stresses that Open VSX, the source its marketplace draws from, never carried the malware, and that Anthropic neither published the rogue builds nor had a flaw in its product. The tampering happened only on Cursor’s copy.

The payload is as described in Cursor’s security notice: host reconnaissance, an SSH key labelled svc-telemetry, persistence (a LaunchAgent on macOS, a SysMon scheduled task on Windows) and an attempted reverse tunnel. The tunnel usually failed without admin rights; the key and persistence did not need them.

On Cursor’s figures, as many as 5,000 users may have pulled the bad builds. Traces from under 0.05% of users outside Privacy Mode leaked, and API keys belonging to under 0.01% of customers were among them. The final attacker activity, on 1 November, was blocked, and Cursor says production, signing keys, the app itself and Privacy Mode data were untouched.

Flow diagram of the Cursor breach from a leaked Fireworks-held key to tampered Claude Code extension builds

Why it matters for UK organisations

AI coding assistants have spread through UK engineering teams faster than most procurement and data protection processes can follow. Many teams will have adopted Cursor via developer-led trials, not supplier review. A review should ask which downstream partners receive your telemetry, which keys they hold, and how long the vendor keeps traces that could contain secrets.

There is also a regulatory side. If Cursor has told you that credentials, support conversations or agent traces belonging to your staff were exposed, you should assess whether that is a personal data breach under UK GDPR. If it is, the 72-hour clock for reporting to the ICO starts when you become aware, not when the vendor finishes its investigation. Exposed API keys may also open systems holding customer data, so a supplier’s breach can quickly become yours. With the Cyber Security and Resilience Bill raising expectations on supply-chain security, boards will want evidence that AI tooling has been through the same scrutiny as any other supplier.

Expert view

When we test development environments, the richest loot is rarely in production. It sits in CI logs, shell histories, ticket attachments and, increasingly, AI session history. This breach is the same lesson at vendor scale. A trace archive kept for model training turned out to be an index of working secrets, and nobody had scanned it.

Credit to Cursor for publishing versions, times, indicators and scripts within a day, and for an apology admitting it “can and must do better”. Even so, a key handed to a partner should have been scoped to a single bucket, limited to known source addresses and set to expire. Each of those controls would have shortened this chain.

In my experience, the extension marketplace is the part that organisations underestimate. An editor extension runs with the developer’s full rights, next to their source code, cloud credentials and SSH keys. A clean version today proves nothing about what ran on 29 October, because the persistence survives updates and uninstalls.

What to do now

  1. Find exposure first. Identify every machine that ran Cursor with Claude Code installed or updated on 29 October. Check authorised keys files for svc-telemetry and check the published fingerprint. On Windows look for the SysMon task and sysmon.cmd in Startup; on macOS look for com.apple.sysmond. Follow Cursor’s security notice in full, and isolate and consider rebuilding any affected host (Cyber Essentials: malware protection, secure configuration).
  2. Act on Cursor’s notices. If you or your admins received a list of exposed keys, rotate every one from a trusted device, highest privilege first, and revoke sessions as well as keys (user access control).
  3. Assess UK GDPR duties. Record the decision on whether this is a notifiable breach, and record the time you became aware.
  4. Enforce Privacy Mode or an equivalent across business accounts. Cursor says traces from Privacy Mode sessions were not exposed.
  5. Scan your own AI history. Run secret scanning over prompt logs, agent transcripts and support tickets, not just repositories.
  6. Control extensions. Allow-list approved extensions in developer tools, turn off SSH and Remote Login where they are not needed, and alert on new authorised keys (secure configuration, firewalls).
  7. Tighten supplier keys. Credentials you issue to third parties should be narrowly scoped, short-lived and restricted by network location.

Bottom line

A partner’s leaked key opened a data store, the data store contained secrets, and those secrets reached a marketplace developers trusted by default. None of that is novel; the volume of secrets AI tooling quietly retains is. Treat agent traces as sensitive data, treat editor extensions as code you deploy, and check every machine that pulled Claude Code through Cursor on 29 October.

Sources

Related Posts