AI coding extensions need an install receipt
In short: A trusted extension ID and version can still hide the wrong build; record its marketplace, install time and artifact digest on every machine.
On 29 October 2026, malicious versions 2.1.312 and 2.1.313 of anthropic.claude-code were served from Cursor's extension marketplace for about eleven hours. The identifier was legitimate. The package was not: it attempted to add an SSH key, open a reverse tunnel and install persistence.
An AI coding extension inventory that records only name and version cannot scope this incident. It needs an install receipt that binds the extension ID and version to its marketplace origin, installation time and artifact digest.
The Cursor incident defeated version-only inventory
Cursor's 29 October notice limits the exposure window to about 2:27 a.m.–1:35 p.m. Pacific time on macOS and Windows. It also says the malicious builds used the expected anthropic.claude-code identifier.
Version alone still does not establish compromise. Cursor says the attacker server is offline and that enabling the local SSH service would fail on most affected hosts because Cursor normally lacked administrator rights. The extension could nevertheless add the attacker's key, send host details and leave persistence artefacts. Uninstalling it may not remove those standalone files.
Microsoft Security Research narrowed the channel further. The malicious packages were never distributed through Microsoft Visual Studio Marketplace or npm, Anthropic's systems were not compromised, and the available evidence limited the incident to Cursor's marketplace.
The same version label can therefore describe different risk depending on source and time. A fleet query for versions 2.1.312 and 2.1.313 finds machines to examine. It cannot tell which bytes reached them.
An AI coding extension install receipt needs five fields
This is editorial judgement, not a Trigent or client deployment. I would keep one row per installed extension on every developer image:
| Field | What it proves during an incident |
|---|---|
| Extension ID | Which logical package the editor loaded |
| Version | Which release label was presented |
| Marketplace origin | Which distribution boundary supplied it |
| Install or update time | Whether the machine fell inside the exposure window |
| Artifact SHA-256 | Whether the installed bytes match a known build |
The receipt supports investigation; it does not certify that a marketplace or signed artifact is safe.
The digest must come from the installed artifact or a trusted deployment record, not from the same catalogue entry being investigated. Cursor published four platform-specific malicious VSIX hashes and a separate payload hash. Those values make a byte-level fleet search possible after the fact. Recording the digest at install time makes the next search faster and preserves evidence when a listing changes.
The receipt changes the first incident-response question
Without provenance, the first question becomes: “Who has this version?” With the receipt, it becomes: “Which machines received this digest from this marketplace during this window?” That query produces a smaller, defensible investigation set.
The receipt does not replace endpoint telemetry. A matching malicious hash shows that the package arrived; it does not show whether privilege-dependent steps succeeded or what an attacker later did. Cursor's indicators and Microsoft's hunting guidance still require checks for the SSH key, persistence files, processes and network activity.
This advances the control in the attacker's secrets inventory. That piece asks whether defenders can find where authority settles on developer machines. This one asks whether they can identify the exact software bytes that gained the chance to search those places.
The number of compromised hosts, any interactive attacker actions and the marketplace compromise mechanism were not established in the primary notices I inspected. The install receipt should narrow uncertainty, not launder it into a clean bill of health.
What's in it for you
- Add marketplace origin and artifact digest to the extension inventory you already keep.
- Preserve install time so a short exposure window becomes a query, not a week of interviews.
- Treat a hash match as an investigation trigger, then use endpoint evidence to determine impact.
Record which extension bytes arrived, from where and when; name plus version is no longer enough.
