Quick summary
- Editor extensions auto-update and run with developer privileges, yet they often fall outside software inventory. The Markdown Preview Enhanced research shows why they belong in supply-chain security governance.
- Developer machines may hold source code, SSH keys, and publishing credentials. High installation counts do not remove the need for risk assessment.
- Build an endpoint extension inventory and review tools that access workspaces or render externally supplied content first.
What happened
Developer dependencies do not end at the package manager. Editor extensions can auto-update and run with the privileges of a user whose machine holds source code, SSH keys, and publishing credentials.
ProjectDiscovery analyzed Markdown Preview Enhanced, reported to have roughly 9.5 million installs, and said it found five CVEs across two attack surfaces. Its report describes a WaveDrom rendering flaw that could turn a Markdown file into JavaScript execution in the preview.
Why extensions are an inventory blind spot
Organizations commonly track application libraries and production images but not extensions by developer and endpoint. That makes it difficult to answer which tools exist on sensitive workstations, who uses them, and how they update.

This is a governance issue, not an argument to ban every extension. Privileged tooling needs assessment proportional to its access.
Classify extensions by access and data path
- Collect extensions from managed endpoints and group them by publisher, version, and workspace use.
- Prioritize tools that read workspaces, render untrusted content, open network connections, or run commands.
- Identify devices with sensitive source, SSH keys, or publishing authority for stricter policy.
- Set review and rapid-remediation paths for newly approved extensions and advisories.
Handle untrusted content as an execution boundary
Markdown files, cloned repositories, and externally supplied documents should not automatically be treated as passive data. For preview tooling, consider opening untrusted content in a lower-privilege environment and apply vendor fixes as they become available.
The research does not mean every extension user was compromised. It demonstrates that familiar tooling can contain a path from content processing to code execution.
What to watch next
Follow ProjectDiscovery’s technical analysis for the reported attack surfaces and remediation context. Add extensions to asset inventory and vulnerability management now.
In 5 Minutes
- Extensions running as developers are privileged dependencies.
- Popularity does not eliminate review requirements.
- Inventory must connect extensions to devices and workspace sensitivity.
- Do not treat untrusted content as harmless data.
Sources
- Securing open source software, together
- Supply Chain Security Analysis of a 9.5M-Install VS Code Extension
- Rust Supply Chain Attack on arrayref: Significant Overlap with DPRK Campaigns
- How to Investigate GitHub PAT Compromise: Lessons From a Multi-Organization Campaign
- Closing the Blind Spot: Securing Personal Repositories in the Software Supply Chain
- keyv and cacheable npm Package Hijacked in Supply Chain Attack
Why developers should care
Developer machines may hold source code, SSH keys, and publishing credentials. High installation counts do not remove the need for risk assessment.
Recommended action
- 1Build an endpoint extension inventory and review tools that access workspaces or render externally supplied content first.

