Response to the malicious Cursor extension

The 2026-10-31 analysis identifies durable evidence and remediation needs beyond removal of [email protected].

Replacing the extension does not remove operating-system persistence, attacker access paths, reverse tunnels, or developer and cloud credentials exposed after execution.

Acting now preserves volatile endpoint and network evidence needed to distinguish installation from execution and to bound the access window.

Because no attached vendor evidence identifies a clean later build, deployment must target a vendor-confirmed clean release rather than an unspecified version after 2.1.313.

Cursor workstations with [email protected] installed, or with extension.js SHA-256 ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15, have confirmed installation exposure and require a vendor-confirmed clean release plus an execution hunt.

Workstations showing correlated extension-host, shell, SSH, filesystem, persistence, reverse-tunnel, authentication, or network evidence face possible operating-system persistence and attacker access and require isolation and remediation.

Developers and cloud-account owners whose credentials were accessible after execution face credential exposure and require rotation. Workstations where attacker authentication succeeded, or where logs cannot bound the access window, face unresolved host integrity and require reimaging.

Endpoint and extension-fleet operators must identify installations, preserve evidence, deploy the confirmed clean release, and route each workstation according to execution evidence.

1) Support — The malware reverser’s 2026-10-31 analysis states that [email protected] and extension.js SHA-256 ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15 establish installation exposure.

It says execution requires corroboration from the Cursor extension-host process tree, shell or SSH commands, filesystem changes, persistence, or network activity.

2) Support — The evidence audit found direct support for investigating runtime, persistence, reverse-tunnel, filesystem, and network evidence and for isolating executed systems, preserving logs, removing persistence, rotating accessible developer and cloud credentials, and conditionally reimaging.

It also found that replacing the extension alone does not remove operating-system persistence, attacker access, tunnels, or credentials exposed after execution. 3) Evidence gap — A second evidence audit found no vendor advisory or release evidence identifying which release after 2.1.313 is clean.

It supports requiring vendor confirmation rather than treating any later version as safe.

The malware reverser’s 2026-10-31 analysis established the key distinction: finding [email protected] or extension.js SHA-256 ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15 proves installation exposure, not execution.

The decision scout translated that distinction into separate exposure-only and execution-confirmed response lanes. The evidence auditor supported the investigation and remediation thresholds but found no vendor evidence identifying a clean release after 2.1.313.

The boundary reviewer therefore rejected wording that could imply every later release is safe. The arbiter resolved the issue by requiring a vendor-confirmed clean release while retaining isolation, credential rotation, and reimaging triggers based on execution and attacker access.

A linking check found no prior Decision Record in the bounded retrieval, so the arbiter selected a new-record outcome.