The VS Code Marketplace sat in an awkward spot through most of 2023 and 2024, with researchers publishing a steady drumbeat of incidents that each individually looked manageable but that collectively painted a picture of a marketplace running on too much implicit trust. The pattern repeated: a researcher would clone a popular extension, change its identifier to a near-miss of the original, push it to the marketplace, and watch as install counts climbed because the search interface ranked the impostor alongside the legitimate extension. In other cases the incident was a real compromise of a publisher account, with the attacker pushing a malicious update to an existing extension and reaching whatever installed base that extension already had. Microsoft's response evolved over the period, but the core architectural gaps remained intact long enough that a clean postmortem in 2026 is worth writing.
This is a composite account rather than a single-incident writeup; the public record across 2023 and 2024 includes work by Aqua, Check Point, ReversingLabs, and independent researchers, and the most useful lessons come from comparing the incidents rather than from any one of them in isolation. The names of the specific malicious extensions have mostly been scrubbed from the marketplace, so the value of the postmortem is in the structural shape, not the specific identifiers.
What was the actual attack pattern across the 2023-2024 incidents?
The most common pattern was straightforward typosquatting against the search interface. A researcher or attacker would pick a popular extension, for example one of the major Prettier or ESLint integrations, and publish a new extension with a display name and description that closely matched the target. The publisher identifier had to be unique, but VS Code's marketplace search prioritizes display name, description, and install count more than it does the verified-publisher state, and a fresh impostor could appear in the search results for the original extension's keywords within hours of publication. Some of the impostor extensions reached tens of thousands of installs before researchers or Microsoft caught them.
The second pattern was account compromise of legitimate publishers. The marketplace authenticates publishers through Azure DevOps personal access tokens, and a publisher whose PAT leaked into a public repository or whose Azure DevOps account had weak credentials gave an attacker direct push access to every extension that publisher owned. Several incidents in 2024 traced back to leaked PATs harvested from CI logs or scraped from public GitHub repositories, and the marketplace had no enforcement against publishing from a token whose entropy or scope looked anomalous compared to the publisher's history.
The third pattern, which showed up more rarely but with higher impact, was extension acquisition similar to the Chrome pattern; a developer with a popular extension would either sell or hand off ownership, and the new owner would push an update that quietly added telemetry, environment variable exfiltration, or worse. The marketplace transfer flow at the time did not require any explicit verification step beyond confirmation in the publisher dashboard, and there was no user-visible indicator that an extension had changed hands.
Why did the marketplace's existing controls fail to stop these?
The structural answer is that the VS Code Marketplace was, and to a meaningful extent still is, a publish-first-review-later system that relies on takedowns after the fact rather than on gates before publication. New extensions go live almost immediately after upload, and the marketplace's malware scanning is primarily automated heuristics that look for known indicators rather than human review. Typosquats slipped through because the indicators in the malicious payloads were often unremarkable; the code might call out to a normal-looking domain, decode strings at runtime, or use Node child processes in ways that are not categorically distinguishable from a legitimate extension that needs to spawn a language server.
The verified-publisher badge existed and was supposed to give users a signal that the publisher had completed identity verification with Microsoft, but the badge was small, appeared in a place users did not look, and was not used to rerank search results in a way that demoted unverified impostors. A user installing a typosquat from search results saw the same UI as a user installing the original, and the verified badge was visible only on the detail page after the user had already decided to install.
The publisher authentication layer used Azure DevOps personal access tokens with long lifetimes, no enforcement of MFA beyond what Azure DevOps itself enforced, and no provenance link between an Azure DevOps build and the VSIX that landed in the marketplace. A publisher could build an extension on a laptop, sign nothing, package the VSIX manually, and push it through vsce publish using a PAT that lived in a .npmrc-like config file. None of the steps in that flow produced an artifact that downstream tooling could verify against the publisher's source repository.
What has Microsoft actually changed since then?
Microsoft has rolled out several incremental hardening measures since the worst of the 2024 incidents. The verified-publisher signal is more prominent in the marketplace UI, with clearer badging on extension detail pages and in some places in the in-editor extension browser. Search relevance has been retuned to demote extensions whose metadata looks like a near-miss of a popular extension's metadata and to surface verified publishers more aggressively. The marketplace has added automated checks that flag extensions whose published artifact contains common indicators of credential exfiltration or of dynamic code loading from remote endpoints, and Microsoft has invested in faster takedown processes when researchers report malicious extensions.
The publisher authentication layer has moved toward more modern primitives. Personal access tokens with broad marketplace scopes are being deprecated in favor of fine-grained tokens and federated identity, and vsce has gained support for publishing through Microsoft Entra ID tokens rather than long-lived PATs. The roadmap for VSIX signing has been on the table for some time and is in various states of implementation; the current state in 2026 is that signing exists as an optional capability and is widely used by a small set of high-profile publishers, but it is not yet a default requirement for marketplace publication and the verification path on the install side is still being filled in.
What has not changed is the absence of cryptographic provenance from source to VSIX equivalent to what npm has been building with sigstore-backed attestations. There is no public attestation that a given VSIX corresponds to a specific GitHub Actions run, a specific commit, and a specific publisher identity verified by Microsoft. Until that exists, a VS Code extension that ships from a CI pipeline cannot be verified against its source the way an npm package with provenance can, and downstream tooling has to either trust the publisher's reputation or do diffing on its own.
What should defenders actually do about this in 2026?
For organizations that ship VS Code as part of a developer workstation image, the practical defense is inventory plus allowlisting plus auto-update controls. VS Code supports policy-based extension allowlists through both managed-installation configuration and enterprise policies, and these let you constrain the set of extensions that can run on managed workstations to a specific list of publisher-and-extension-ID pairs. Combine that with version pinning where the marketplace supports it, and a malicious update to an allowlisted extension still has to clear whatever review and approval process you put in front of version bumps before it reaches your developers.
For organizations whose developers install extensions freely, the defense is closer to detection than prevention. Track which extensions are installed across the population, diff VSIX contents across versions for unusual changes in network endpoints or in the set of dependencies pulled into the bundle, and watch for publisher ownership changes or for sudden permission expansions in extensions that historically were narrow. The marketplace API exposes enough metadata to drive most of this, and the cost is mostly engineering time to build the pipeline.
For the high-value workstation case, particularly developers who work on infrastructure or who have direct access to production secrets, the strongest defense is to treat the workstation as a regulated environment where extensions are evaluated like vendor software, not like consumer apps. That means a security review before a new extension is added to the allowlist, a renewal process when the extension changes hands or significantly changes behavior, and a documented expectation that anything outside the allowlist is presumed to be untrusted regardless of how popular it is on the marketplace.
How Safeguard Helps
Safeguard treats the VS Code Marketplace as a vendor ecosystem and tracks installed extensions across developer workstations the same way it tracks npm dependencies and container images. Our inventory records publisher identity, verified-publisher state, version history, and VSIX content fingerprints, and Griffin AI flags ownership transfers, anomalous network behavior, and known impostor patterns automatically. Reachability analysis correlates which extensions actually interact with sensitive paths on the developer machine versus which ones run idle in the background, so prioritization for review reflects real exposure. TPRM workflows let you treat each publisher as a vendor with a risk profile and require explicit approval before a new extension reaches a managed workstation. Policy gates enforce allowlists, signature checks where available, and version pinning across the developer fleet, and SBOM exports keep the workstation extension inventory inside the same compliance evidence as the rest of your stack.