Audit of top 100 VS Code extensions finds 19 shipping dependencies with known CVEs

An independent audit of the 100 most-installed third-party VS Code extensions has found that 19 of them ship at least one dependency carrying a known vulnerability. The most striking single result: Live Server, an extension with more than 84 million installs, bundles websocket-driver 0.7.4, a version covered by a critical advisory tracked as GHSA-xv26-6w52-cph6 and CVE-2026-54466. The audit was published on dev.to on 10 November 2026 by Vadim Toptunov, using a Marketplace snapshot taken on 8 November.

What the scan found

Nineteen of the hundred sampled extensions contained at least one dependency-version pair that matched an advisory in the OSV.dev vulnerability database. Counted as extension-dependency pairs rather than extensions, the scan logged 103 affected combinations tied to 149 distinct advisory records. Ranked by each pair's worst severity, 12 are critical, 61 high, 24 moderate and 6 low.

Live Server tops the affected list at 84,254,316 installs, and its flagged packages extend past websocket-driver to include braces, lodash and js-yaml. Code Runner follows at roughly 42.7 million installs with a high rating, and the high band also contains Path Intellisense, the Django extension, PHP Debug, Vetur and EditorConfig. Critical advisories also matched indent-rainbow, DoxyDocGen, Beautify, which ships a version of minimist flagged for prototype pollution, plus PlatformIO IDE and Bracket Pair Colorizer 2, among others.

The same npm packages recur across many extensions, with lodash, minimatch, braces, brace-expansion and semver the most frequent, which is why a single advisory often maps onto several extensions at once.

Present, not proven exploitable

The author is careful about what the numbers mean. Every finding sits at what the audit calls the Present level: the vulnerable package name and version exist inside the shipped .vsix file. Nothing in the scan demonstrates that any of this code is loaded at runtime, reached during normal use, or exploitable by an attacker. The audit defines four escalating levels, from present through loaded and reachable to exploitable, and claims only the first for every row.

How the audit was run

The method is deliberately inexpensive: roughly 15 minutes of runtime with Python's standard library and three public APIs, none requiring authentication. Toptunov pulled the top 200 Marketplace entries by install count, removed first-party publishers such as Microsoft and Red Hat along with themes, language packs and keymaps, and kept the top 100 of what remained. Each .vsix, about 1.6 GB in total, was downloaded and unzipped, and every package.json under node_modules was enumerated, yielding 1,357 nested manifests covering 935 unique name-version pairs, before being batch-checked against OSV.dev.

One limitation cuts against the headline number. Sixty-four of the hundred extensions shipped no node_modules directory at all, typically because they are compiled into a single JavaScript file by bundlers such as esbuild or webpack. The scanner cannot see inside those bundles, so the count of 19 is what the method could observe, not necessarily a ceiling.

Why advisories never catch published bundles

The structural problem the audit highlights is timing. An extension's dependencies are locked inside its .vsix on the day it is published. When an advisory appears weeks or months later, it does not flow back to already-published bundles, and Toptunov could not find a publicly documented Marketplace mechanism that re-checks published extensions against new advisories or notifies maintainers or users. VS Code's interface also gives users no way to inspect the dependency footprint of an extension before installing it.

The audit notes that Workspace Trust, introduced in VS Code 1.57 in May 2021, already curbed the older class of attacks where opening an untrusted repository could trigger malicious extension behaviour. That gate, however, does nothing about vulnerable third-party code already inside legitimate extensions.

Why it matters

Marketplace extensions reach tens of millions of developers, and every install places a maintainer's dependency tree onto a developer's machine with no dependency-level visibility and no post-publication review. The 19 affected extensions are not proven attack vectors, since the findings are about presence rather than exploitability, but the ecosystem currently has no feedback loop at all: advisories get published, yet nothing tells anyone that a shipped extension now contains a known-vulnerable package. Because the audit needed only unauthenticated public APIs and a few hundred lines of stdlib Python, continuous scanning of the Marketplace is technically trivial; the gap is product and process, not capability. For maintainers of the affected extensions, the practical step is rebuilding and republishing against current dependency versions, because those bundles will not update themselves.