Malware in Cursor’s Marketplace: Should Updates Wait?

A Cursor user wanted to keep automatic updates on. The request, posted on October 30, was to let a new extension version wait before installing it automatically. Turning updates off altogether, the user wrote, was too drastic. A reply later that day linked the official documentation: a delay was already possible for teams and individuals. The request and reply

The exchange followed Cursor’s October 29 notice that maliciously modified versions of the Anthropic.claude-code extension had appeared in its marketplace. Cursor identified versions 2.1.312 and 2.1.313 and said Anthropic had not developed the malicious versions. Its notice addresses people who installed or updated to those versions but gives no breakdown of automatic installations. That distinction rules out a neat story in which one delay setting would demonstrably have stopped this incident. Cursor’s notice

What the exchange does show is a choice between receiving new software immediately and allowing time for somebody to inspect it. Cursor’s current documentation calls the feature Marketplace Install Cooldown. A version must have been published for a minimum number of hours before installation or update. The default is zero, with the delay disabled. Team owners and administrators can impose a positive value across their fleet, overriding individual settings. Individuals can choose their own delay when the team has not enforced one. The documentation has no publication date; I could not establish when the feature became available. Cursor’s documentation

“Already possible” therefore settles only part of the question. The exchange leaves unanswered what this user knew, what was available when the attack occurred and which policy the user’s team applied. It also leaves the important decision above the individual when a team enforces a delay. A developer’s willingness to receive a release immediately does not override that rule.

There is a long-standing security reason to distribute updates quickly. In April 2010, Microsoft recommended automatic updates so that people would receive its latest security and reliability fixes. That was a vendor’s advice, not a measurement of how the whole software industry behaved. Its rationale remains relevant to any proposed wait: a legitimate repair cannot protect a machine until it reaches it. Microsoft’s 2010 explanation

Organizations have also made room for testing before wider deployment. Microsoft’s Windows update policy documentation, last updated in September 2025, describes grouping devices by deferral period and updating a small pool first to verify quality. Waiting there is attached to a process that produces information. It has a purpose beyond letting the calendar advance. Windows update policies

In September 2025, the package manager pnpm introduced a minimum release age for dependencies in response to supply-chain attacks. Its release announcement describes delaying installation after publication and allowing selected dependencies to be excluded. These are dependencies rather than Cursor extensions, and the distribution systems differ. The shared idea is to make a release’s age part of the installation decision, giving detection and removal time to work. It is not a test that proves the software harmless. pnpm’s announcement

The danger comes from both directions. A malicious release may be withdrawn during the wait. A security repair may spend the same time waiting outside a vulnerable machine. That second consequence is my inference from a policy covering updates as well as first installs. I found no emergency-fix exception in the Cursor cooldown section I examined. Other documentation or controls may provide such a route; I did not verify one. The user’s proposal would have exempted manual installs; I could not confirm that exemption in the current product documentation I read.

Cursor says the delay complements marketplace analysis and blocking. Its incident notice describes removing the malicious versions, interrupting distribution and working to disable the attack server. Those remain the provider’s responsibilities. A user’s decision to wait cannot substitute for checking what the marketplace serves. Availability alone supplies no evidence of reduced harm in use. Cursor’s documentation, incident response

My view is that the wait belongs in the update policy people can actually understand and govern. A team that chooses it should say who watches for new information during that interval, when the wait ends and who can authorize an urgent repair. A product that offers it should make those choices visible alongside the switch for automatic updates. Otherwise an individual asking for time may discover that the real choice has already been made elsewhere.

For an assistant asked to install a tool, this means treating the team’s wait as part of its permission to act. If an urgent repair appears to justify an exception, the assistant should bring that decision to whoever controls the policy. Speed is a useful service within the authority it was given.

The October request is one person’s proposal, not a survey of developers. It is enough to identify a useful design demand. Software can remain automatic while its arrival is governed. The value of the pause depends on what happens during it and who is answerable when it must end.