Check V9 · execution family · automatic · one of the 17 VS Code Marketplace checks
The question this check asks: when you install this extension, what else arrives with it — and would you have installed each of those on its own?
Two manifest fields turn one install into several. extensionPack bundles a set of extensions that install together; extensionDependencies names extensions this one needs to run, which the editor installs automatically. The gallery carries both as properties — Microsoft.VisualStudio.Code.ExtensionPack and Microsoft.VisualStudio.Code.ExtensionDependencies. The legitimate use is everywhere: 19 of the 100 most-installed extensions pull others in.
The threat shape is the inversion: the parent looks ordinary and the payload rides in as a member. Socket's research team documented it at scale on 13 March 2026 — "at least 72 additional malicious Open VSX extensions" in the GlassWorm v2 campaign, delivered through extensionPack and extensionDependencies; "As of March 13, Open VSX has removed the majority". Socket's update of 29 April 2026 described the campaign's activation wave "via transitive delivery": 23 new malicious versions across 22 copycats. That was Open VSX — the registry VSCodium, Cursor and Windsurf install from — which this roster does not assess. The mechanism is identical on the Microsoft Marketplace, and V9 is built for the shape, not the registry. Its GitHub analogue is C12: a repository whose .gitmodules pulls another repository in.
V9 belongs to one dimension, install and run (V6, V7, V8, V9, V11, V12) — the pack is a fact about what installing does, not about opening the editor or handing the extension to an agent.
V9 collects member ids from all four places — both gallery properties and both manifest lists — and de-duplicates them. One extra gallery query fetches the members' own records, and each is assessed one level deep with four tests borrowed from the roster: is the publisher not domain-verified and the member's listing under 90 days old ("new, unverified publisher" — V1's HIGH condition); is the latest version missing its signature asset ("unsigned" — V6); do the listing's flags lack validated ("not validated" — V11); does the publisher, name or display name imitate a known extension ("lookalike name" — V4's rules). Any yes produces vsx-pack-weak:<id>, HIGH, 12 points, with the reasons listed in the finding. None produces vsx-pack:<id>, INFO, "installed alongside". A member the gallery did not return is also INFO, "installed alongside — not assessed on this pass". The scoring table's two evidence notes, verbatim:
"V9; installed alongside"
"V9; a pack member that is new-and-unverified, unsigned, not validated or a lookalike"
The verdict engine behind all 17 checks: any CRITICAL finding is BLOCK; any HIGH or MEDIUM is REVIEW; INFO only is PASS. The score is separate — 100 minus every fired penalty, floored at zero; 80 and above green, 50 to 79 amber, under 50 red. One weak member is a REVIEW at 88; two, a REVIEW at 76. No member finding is a CRITICAL, so V9 on its own never moves the parent to BLOCK — the preflight for code --install-extension and the MCP tools see the profile's warn action and name the member, so the person installing can assess it on its own key before going ahead.
In the 18 September 2026 measurement of the 100 most-installed extensions, 19 pull others in, and none of their members graded weak — nineteen notes, zero points. The run came out 99 PASS, 1 REVIEW, 0 BLOCK. The false-positive shape is a pack whose maintainer adds a companion extension of their own under a fresh publisher id, or one so new the Marketplace has not yet marked it validated: the pack is a REVIEW on the member for the member's first 90 days, or until the member's domain is verified or its flag arrives. The finding names the member and the reason, and the cost is the warn action, not a refusal.
One level, four tests. A member's own pack and dependencies are not followed — the "transitive delivery" Socket described in April 2026 is exactly a payload two hops away, and V9 sees one hop. The rest of the roster does not run on a member here: its source repository, the contents of its package, the proposed APIs it declares, the agent files it ships. Assess the member on its own key, vsx/{publisher}/{extension}, for those. And the registry where the 72 lived — Open VSX — is out of scope entirely. RepoGates assesses a Marketplace extension on request — through the API, the MCP server (platform="vsx") and the preflight for code --install-extension. It does not see an extension installed from the editor's own UI, or one that auto-updates; the board on marketplace pages is not built yet; Open VSX (where VSCodium, Cursor and Windsurf install from) is a different registry and is not assessed. The extension's code bundle is not read on this tier: a PASS means the provenance and the declared surface are clean, never that the JavaScript was inspected.
Open the extension's package.json — the gallery serves it as the Microsoft.VisualStudio.Code.Manifest asset — and read extensionPack and extensionDependencies; the Marketplace listing page shows pack members under their own tab as well. Then take each member id and ask of it what V9 asks: a blue verified-domain mark beside the publisher, a first-release date more than 90 days back, a signature asset on the latest version, the validated flag on the gallery record, and a name that is not one edit from something you already know. Or request the member through RepoGates on its own key for the full roster.
Does V9 treat a pack member and a dependency differently? No. An extensionPack member is bundled for convenience and an extensionDependencies entry is required to run, but both arrive on the developer's machine when the parent is installed, and that is the only fact this check cares about. V9 reads both gallery properties and both manifest lists, de-duplicates the ids, and grades every member the same way.
How deep does V9 look? One level, with four tests. The members are fetched in one extra gallery query and each record is asked: is the publisher unverified and the listing under 90 days old; is the latest version unsigned; is the listing not marked validated; is the name a lookalike? Any yes is vsx-pack-weak, HIGH at 12 points. A member's own pack and dependencies are not followed, and the rest of the roster — its source repository, its contents, its proposed APIs, its agent files — is not run on it. For those, assess the member on its own key.
Would V9 have caught the 72 extensions Socket found delivered this way? Not as they were published, because they were on Open VSX — the registry VSCodium, Cursor and Windsurf install from — and this roster does not assess it. Socket's 13 March 2026 finding is the shape V9 is built for: a parent that looks ordinary and a payload that rides in as a pack member or a dependency. The mechanism is the same on the Microsoft Marketplace, and there a member from a fresh unverified publisher, or unsigned, or not validated, or wearing a known name, is a HIGH on the parent before either is installed.
V1 Publisher verification — the first of the four weak tests, applied to each member's publisher · V6 Package signature — the second: a member whose latest version the Marketplace has not signed · V11 Marketplace validation — the third: a member the platform's own gate has not passed · C12 Submodule definitions — the GitHub analogue, a repository that pulls another repository in at checkout.
Add RepoGates to Chrome Pricing
Numbers on this page: the 18 September 2026 measurement of the 100 most-installed extensions on the VS Code Marketplace, run locally through the same code as /v1/vsx/score; campaign facts as published by Socket's research team (13 March and 25 and 29 April 2026); weights from the product's scoring table.