The Claude Code Extension Incident: A Cleanup Guide
Matthew Leo · Published October 31, 2026 · Guides
Cursor says two releases of a Claude Code-branded extension in its marketplace were tampered with on October 29, 2026. The affected versions, 2.1.312 and 2.1.313, could install a persistent remote-access mechanism on Windows and macOS. Cursor estimates that up to 5,000 users may have been exposed.
This is not an ordinary “uninstall the extension and move on” event. Both Cursor’s security notice and Microsoft’s technical analysis say removing or updating the extension does not necessarily remove the persistence it created. The response needs to treat the computer as potentially accessed by someone else.
Who should investigate
Start with any Windows or macOS computer that installed or automatically updated the marketplace extension to version 2.1.312 or 2.1.313. Cursor says the malicious releases were available from about 2:27 a.m. to 1:35 p.m. Pacific time on October 29. The company has taken the extension offline and says it has not found evidence that other versions or extensions were affected.
That last point narrows the first search, but it should not end it. Teams should verify versions from their own extension inventory, endpoint telemetry and software-management records rather than relying on memory. A developer who never opened the extension may still have received an automatic update.
Use this response order
1. Preserve evidence before cleaning
Record the device name, user, installed extension version and relevant timestamps. Preserve endpoint alerts, process trees, network logs and authentication records. If your organization has an incident-response process, involve it before running cleanup commands that may erase useful evidence.
2. Isolate a suspected device
Disconnect the computer from normal network access or use your endpoint platform’s containment feature. Do not use the suspected computer to download sensitive recovery material, rotate credentials or sign into administrative consoles. Use a known-clean device for those actions.
3. Follow the vendor checks, not a copied indicator list
Cursor’s notice includes current checking and remediation scripts for Windows and macOS. Use the scripts from that official page and preserve their output. The vendor lists persistence involving SSH authorization, startup or scheduled execution, hidden local files and a background service. Microsoft also describes tunnelling that could allow later access.
Indicators can change as an investigation develops. Linking to the maintained vendor notice is safer than relying on an old copy of a key, address or filename in a local checklist.
4. Review what the device could reach
Look for suspicious logins, new SSH keys, unusual Git activity, cloud-console access, package-registry changes and secrets read from the machine during the exposure period. Prioritize credentials that were stored on the device or used after the affected extension was installed: source-control tokens, cloud credentials, package publishing keys, deployment secrets and privileged accounts.
Rotate exposed credentials from a clean device. Revocation should come before replacement where possible, so an old token cannot remain valid beside the new one. Canadian organizations with regulated or sensitive data should also document whether the facts trigger contractual, privacy or cyber-incident reporting duties.
5. Rebuild when trust cannot be restored
A script can remove known artifacts; it cannot prove that an attacker made no additional changes after gaining access. If the computer handled high-value credentials, shows unexplained activity or lacks adequate telemetry, rebuilding it from trusted media is the safer choice. Restore only reviewed data and reinstall extensions from approved sources.
What development teams should change next
Keep an extension inventory: record extension identifiers, publishers and versions on managed developer machines.
Control automatic updates: use staged deployment or an allowlist for extensions that can execute code or access repositories.
Separate development secrets: prefer short-lived credentials and workload identity over long-lived keys stored on laptops.
Monitor persistence paths: alert on new SSH authorized keys, launch agents, scheduled tasks and unusual outbound tunnels.
Plan for marketplace failure: a familiar name is not proof that a package or extension is authentic.
The pattern resembles other software-supply-chain incidents: the first compromised component is only the opening move. Mapletechie’s ConnectWise tenant-hunt guide explains why responders must investigate every system the initial access could reach.
The practical takeaway
Users on other extension versions do not need to assume compromise based on the information available on October 31. Anyone who had 2.1.312 or 2.1.313 should, however, treat the device as potentially accessed, preserve evidence, contain it, use Cursor’s current remediation material and rotate exposed credentials from a clean computer. Reuters independently reported Cursor’s estimate of up to 5,000 potentially affected users.
Tags: cybersecurity, software supply chain, incident response, Cursor