Taking an attacker's server offline sounds like a satisfying end to an incident. In the Cursor marketplace case, it's welcome progress with an unfinished job attached: the affected developer's computer can still have unwanted software and an unauthorized access key sitting on it.
Cursor's October 30 update to its Claude Code extension warning now identifies versions 2.1.312 and 2.1.313 for Windows and macOS. The company says malicious packages were available through its marketplace on October 29, weren't developed by Anthropic, and could leave background scripts running after uninstall. It has removed the packages and worked with the hosting provider to take the attacker's server offline.
I'd be pleased about that last part. I'd still want to know what happened on the computer that opens my company's website project.
A smaller exposure question is a better starting point
This is about particular versions from a particular marketplace. Cursor says it has no evidence that other versions or the official distribution are affected. A business doesn't establish exposure simply by discovering that its agency uses Claude Code.
The useful opening conversation is much narrower: did anyone working on our projects install either affected version from Cursor's marketplace? That gives a developer or agency something concrete to check. A broad demand to explain every AI tool in the building would turn a specific incident into an argument about purchasing policy.
There is also a reassuring technical limit. Cursor says errors in the malicious code and the need for administrator rights would prevent the remote-access step on most ordinary Windows and macOS setups. That doesn't make cleanup optional; it does make a claim that every affected computer was remotely controlled too strong.
The work can survive the uninstall
OpenSourceMalware's analysis of version 2.1.313 describes malicious code running before the legitimate extension initializes, with separate files intended to keep a remote-access connection alive. Its presence didn't depend on the user starting a conversation with Claude. A familiar interface could keep working while something else happened underneath.
For a small business, the uncomfortable part is how ordinary the arrangement can be. Consider an illustrative web agency whose developer works on several customers' sites from one laptop. A clean-looking project preview tells the customer very little about that laptop. Equally, a problem on the laptop doesn't automatically establish that every customer's site or records were accessed. The investigation has to connect those dots.
I'd pay for that distinction to be worked out properly. Removing the extension is an action; deciding whether the workstation and its accessible accounts can be εμπιστοσύνηed again is a separate piece of work. The person doing the response should use the current vendor guidance, preserve useful evidence, examine persistence and account exposure, and explain whether rebuilding the computer is warranted. That is a scoped incident response, rather than another routine software update.
If an agency says the extension is gone, a reasonable follow-up is: what did you find beyond it, and what does that mean for our project? An answer can be reassuring without pretending that an uninstall button settles everything.
The marketplace can be back online before the customer's work should resume on an affected machine. I'd rather allow time for the second decision than mistake the first one for the finish.
Sources and further reading
