Cursor’s malicious extension: what recovery needs to prove

An October 30 follow-up to an October 29 incident

Cursor’s October 29 notice identifies modified Anthropic.claude-code 2.1.312 and 2.1.313 packages distributed through its marketplace for Windows and macOS. An October 30 update, marked 11:30 a.m. PT, clarified indicators and affected versions. Cursor says it removed the packages and disrupted the attacker’s server. Those actions describe service containment, not a reader’s endpoint.

For a team reading the news this morning, we propose starting with a bounded question: what evidence would establish whether this particular installation passed through the affected distribution route? Retain the observed source, version and installation history before drawing a conclusion from a familiar extension name. A record that cannot answer the source question should keep that uncertainty visible.

Source notes: 1. Original editorial examples and interpretations are identified separately.

Code capability is different from a measured intrusion

Microsoft’s October 30 analysis describes injected JavaScript attempting SSH access and writing startup artifacts. Successful access depends on the host’s configuration. Microsoft says the malicious packages were not distributed through Visual Studio Marketplace or the official npm package; Anthropic told Microsoft its systems were not compromised. The reporting callback collected environment-variable names rather than values. Written artifacts can remain when a tunnel fails.

Microsoft attributes the distribution window to Cursor: about 2:27 a.m. to 1:35 p.m. Pacific Daylight Time on October 29. Its recovery guidance recommends preserving evidence, correlating telemetry and removing confirmed malicious artifacts; an absent marker alone is insufficient. It warns that uninstalling the extension or disabling the server does not erase changes already made outside the extension directory.

Our reading keeps four questions separate: was the package acquired, did its loader execute, what changes occurred, and was remote access established? An answer to one question cannot stand in for the remaining answers. This distinction also sets a useful limit on reporting: a description of attempted behavior should not become an invented count of successful break-ins.

Source notes: 2. Original editorial examples and interpretations are identified separately.

Make the first handover useful to the responsible team

Our proposed handover begins with the reason for concern and the observation that triggered it. Keep relevant records in the organization’s protected incident channel, with the device’s responsible owner and the time of the observation. Avoid circulating a broad bundle of personal files or secrets merely to make the report look complete. The people investigating should decide what additional evidence they need.

Describe missing information precisely. “Installation source not yet established” is a different problem from “source established and outside the reported route.” Likewise, an extension inventory that lacks historical versions should not be presented as a complete history. This proposed wording helps a colleague continue the investigation without inheriting an unjustified clean bill of health.

Source notes: 1, 2. Original editorial examples and interpretations are identified separately.

Define what would close each recovery decision

We suggest separate entries for containment, investigation and restoration. Each entry needs an owner, the action taken, the observation obtained and the remaining uncertainty. This is an editorial recording method, not a replacement for current vendor instructions or the organization’s incident process. It should remain small enough for the responsible team to maintain.

For example, a team might record that it has completed an approved containment action while leaving restoration pending. The next entry should state the evidence the team requires before that second decision can be made. Recording a condition as pending is useful work: it prevents urgency to resume ordinary tasks from silently changing an unresolved question into an assumed result.

A manager asking whether everyone can return to work should therefore receive a decision and its scope, rather than a list of tools that were opened. In our proposed record, the person authorizing restoration can point to the evidence reviewed and the limitations accepted. Lumacta has not made that decision for any reader or examined any device.

Source notes: 2. Original editorial examples and interpretations are identified separately.

Use current guidance without inventing a universal cleanup

This article is a route into the linked notices, not a script to paste into a terminal. Have the responsible administrator review the guidance against the actual system and preserve the evidence the investigation needs. Our proposal is to record which instructions were followed, their source and their retrieval time, so a later reviewer can understand the basis of the action.

If access to a source fails, retain that failure and seek the normal support route. Do not fill the gap with commands copied from an unattributed social post. A recovery record can identify an unresolved dependency on expert assistance without pretending that an improvised procedure has been checked or that the reader’s device now meets an unexamined definition of safe.

Source notes: 1, 2. Original editorial examples and interpretations are identified separately.

An update delay needs an owner and an exception path

Cursor’s hardening documentation describes trusted-publisher restrictions and an extension-install cooldown, with optional signature verification. Most organization-wide policy and device-management controls in that document are Enterprise features. Treat it as rolling product guidance; the page does not provide a dated experiment measuring the protection achieved by a particular delay.

Our practical question is who owns the tradeoff between waiting for a new release and receiving an urgent legitimate fix. A team considering a delay should define a review point and an exception route rather than turn the delay into a promise of safety. An exception should record why it exists and which person remains responsible for following it through.

Source notes: 3. Original editorial examples and interpretations are identified separately.

The evidence boundary remains part of the story

This is a dated follow-up based on October 30 documentation, using the 24–48-hour reporting extension; it does not announce a fresh November 1 attack. Our recovery record is a proposal. We performed no endpoint examination, malware execution, cleanup-script test or comparison of security products. The archive photograph is generic laptop context and does not show Cursor, a compromised machine or a Lumacta test.

Source notes: 1, 2, 3. Original editorial examples and interpretations are identified separately.