Extension update authority is the decision about who can change code on an engineering endpoint without an acquisition event the organization controls. On October 29, 2026, that decision was tested in the Cursor VS Code Extension Marketplace. According to Cursor, a maliciously modified Anthropic.claude-code extension, versions 2.1.312 and 2.1.313 in Windows and macOS packages, was available between about 2:27am and 1:35pm PT, roughly eleven hours. Cursor states that Anthropic did not develop the malicious versions.
The sources are specific enough to separate three responsibilities that an editor's extension feature quietly bundles together: the permitted update path, the activation boundary, and recovery. They are not specific enough to say how the package got into the marketplace, and this post does not pretend otherwise.
What the Sources Establish, and What They Do Not
This post rests on two primary sources: Cursor's security notice and Microsoft Threat Intelligence's analysis of the injected code. Every claim below is attributed to one of them.
| Established by the sources | Not established |
|---|---|
| The injected loader runs when the extension module loads, before normal extension initialization, and the extension keeps working (Microsoft) | How the package was first admitted to the marketplace, or which control failed. Cursor's notice gives no root cause |
| Persistence is written outside the extension directory. Microsoft states that removing or updating the extension does not remove it, and Cursor says uninstalling may not be sufficient | Whether any host was accessed through the tunnel |
| The loader reports environment-variable names, not values (Microsoft) | Whether credential values were taken |
| The malicious versions were removed, the marketplace was shut down, keys rotated and the marketplace rebuilt (Cursor) | Anything beyond Cursor's own statement that its audit found no other tampered extensions |
Scope of the evidence:
- Windows and macOS packages are the identified affected packages. Microsoft's analysis shows Linux crontab logic in the loader, and Cursor's indicators list Linux persistence artifacts, but neither identifies an affected Linux package.
- The loader attempted SSH key installation, SSH enablement, a reverse tunnel and persistence. Cursor says the key and persistence were written and host details sent even where the tunnel failed. Microsoft lists these as attempted actions and says the sequence does not prove every step succeeded on every host.
- Cursor says SSH enablement failed on most macOS and Windows hosts, citing errors in the malicious code and the administrator rights the step requires. ## Extension Update Authority: Who Governs the Channel
Microsoft's guidance tells organizations to find systems that "installed or automatically updated" the affected versions through the Cursor marketplace. Automatic update turns the marketplace operator's publishing decision into a change on each eligible endpoint that has the extension installed and automatic updates enabled. The organization made a deployment decision whether or not it ever wrote one down: it permitted a channel to change executable code on AI infrastructure engineering endpoints on the channel's schedule.
The acquisition record cannot capture that. The OVHcloud release-tags post records what a pipeline fetched and validated at acquisition. An extension that updates itself has no such moment on the consumer side, so the first thing to govern is extension update authority: which channels may install and update, and under what conditions.
Microsoft points to controls from Cursor's security-hardening guidance: restricting extensions to approved publishers, and an installation cooldown that delays newly published versions. Both are real controls. Neither is extension update authority itself, and each carries an assumption. An approved-publisher list is only as strong as the identity and provenance checks behind it. This package carried the Anthropic.claude-code identifier while Cursor says Anthropic did not develop it, and whether a publisher list would have stopped it depends on what the marketplace verifies, which the notice does not say. A cooldown helps only if it outlasts the time a bad version stays available, and by Cursor's times that was about eleven hours. The version label is not the control either: Cursor lists modified packages for 2.1.312 as well as 2.1.313.
Who admitted the package into the channel is a separate authority, and nothing disclosed shows how it failed. The point for the architect is narrower: admission, update and activation are separate lifecycle decisions, and each needs a named owner.
Activation Runs While the Extension Still Looks Normal
Microsoft's analysis describes a JavaScript function that executes before the extension's expected code. When the module loads, it can use Node.js APIs to collect host information, modify files and execute operating-system commands. It suppresses command output and silently catches errors, while the extension continues functioning normally. The loader ran in the extension's execution context. Cursor attributes the failure of the SSH step to errors in the malicious code and to the administrator rights that enabling the local SSH service generally requires.
Extension update authority decides when new code arrives. The activation boundary decides what that code can do on arrival, and it is the earliest critical execution boundary. By the time the module has loaded, the extension has already begun executing code, and the user sees an extension that behaves as before. Endpoint detection, process controls and isolation can still act, but they act on code that is already running. The architect needs to know, per extension class, what loading it permits, and which telemetry would show a change at editor start: file writes outside the extension directory, new startup objects, new outbound SSH processes. The same boundary question applies to tools an agent registers from a hub, which MCP security architecture maps. The difference here is that the extension's code executes at module load, before normal initialization, with no tool call or approval in the path.
Recovery Proof Is Not Package Removal
Uninstall removes the package. The artifacts it wrote outside its directory can stay.
Microsoft states that removing or updating the extension does not remove what it wrote outside its directory, and Cursor says uninstalling may not be sufficient. Microsoft adds that Cursor's takedown of the attacker's server does not remove artifacts already on a device. The Server Was Fixed. Persistent Access Wasn't. names the general pattern: remediation that succeeds on the layers it was scoped to and never reaches the layer persistence lives in. Here the package is the layer that removal reaches. A recovery runbook has to be built on that, in this order:
- Preserve evidence before cleanup: the extension package, the modified SSH authorization files, generated keys and scripts, and startup configuration (Microsoft).
- Identify and remove the documented persistence and unauthorized processes. Cursor documents a LaunchAgent on macOS, a scheduled task with a Startup-folder fallback on Windows, scripts and identity files under a
.configdirectory, and a key labeled svc-telemetry. Microsoft says to inspect each startup object's configured action before removal, because names alone do not distinguish malicious objects from legitimate monitoring software. - Assess whether the endpoint can be trusted or must be rebuilt (Cursor, Microsoft).
- Rotate credentials and sessions reachable from the host, from a trusted system. Cursor says limited environment-variable collection does not rule out later credential access over the backdoor. Microsoft ties rotation to telemetry showing credential access or to device trust that cannot be restored. What rotating them actually revokes is the revocation unit question.
- Verify recovery independently of whether the package is gone: confirm the tunnel and startup artifacts do not return after login or restart (Microsoft). Extension update authority governs how a package arrives. Recovery has to be proved on the endpoint, and a clean extension list is not that proof.
Three Responsibilities, Three Failure Consequences
Each responsibility needs an owner and the evidence that owner can produce.
| Responsibility | Organizational responsibility | Evidence required | Failure consequence |
|---|---|---|---|
| Extension update authority | Endpoint fleet owner governs permitted channels, update policy and deployment conditions | Approved channels, update mode, extension inventory, installation and update timestamps | A channel changes executable code on engineering endpoints with no organizational decision in the path |
| Activation boundary | Endpoint security sets execution controls and verifies what an extension actually does at load | What runs at load, with which privileges; file, process and startup-object telemetry at editor start | The loader executes at module load while normal extension behavior continues |
| Recovery | Incident owner holds the runbook for persistence removal, rebuild decision and credential rotation | Preserved evidence, documented artifacts removed, rotation from a trusted system, a check after restart | The package is gone, the persistence and credentials are not, and the endpoint is treated as clean |
Admission is a separate question: who may put a package into the channel at all. Nothing in the disclosures shows how it failed here, which is a reason to assign it, not a finding about it.
Architect's Verdict
An extension is executable software with an independently governed acquisition, update, activation and recovery lifecycle. Treating it as an editor feature leaves all four to defaults.
The real problem is extension update authority. An automatically updating extension creates an organizational deployment decision, whether or not the organization has explicitly governed it. On October 29 the exposure window, by Cursor's times, was about eleven hours, and the loader ran at module load while the extension kept behaving normally. Whoever answers for the engineering fleet answers for that decision.
For each extension class on engineering endpoints, name three owners before the next incident: who holds extension update authority and governs the permitted update path, who establishes and verifies the activation boundary, and who owns recovery, including persistence removal and credential rotation. Write the runbook so it ends in a check that does not depend on the extension being gone, and keep admission as its own governance question.
Removing the package is not recovering the endpoint. The decision about what the extension was allowed to do has to exist before anyone needs it.
Originally published at rack2cloud.com
