Researchers Find Five Flaws in a VS Code Extension Used by 10 Million Developers

A VS Code extension used by more than ten million developers had a chain of security bugs. A booby-trapped markdown file could use them to write files onto a victim’s machine. Researchers at ProjectDiscovery found the flaws in Markdown Preview Enhanced and disclosed them in early June. The maintainer shipped fixes within days. This VS Code extension vulnerability matters well beyond hobbyist coding. Developer laptops sit close to source code, credentials and build pipelines.

Inside the VS Code extension vulnerability

Markdown Preview Enhanced shows a live preview of markdown files inside VS Code. That includes diagrams written in a format called WaveDrom. To turn diagram text into a picture, the extension ran it through JavaScript’s eval() function. Eval() runs whatever text it is handed as code. The diagram text comes straight from whatever file is open. An attacker only needed a victim to preview or export a crafted .md file.

That flaw is tracked as CVE-2026-50733 and scored 8.8 on the CVSS scale. Once code ran inside the preview window, it could reach further. It found an unsanitised messaging channel between the preview and the extension itself. From there, it could write files to the developer’s disk, according to ProjectDiscovery’s write-up. Shell start-up files, Git hooks, build scripts and SSH configuration all sit within reach. Any process that can write anywhere on the file system can reach them.

Four more bugs stack on top

ProjectDiscovery’s researchers did not stop at one bug. They also found four more issues. One was a sandbox escape reachable through the extension’s project configuration files. Another was a stored cross-site scripting flaw in an HTML template the extension loads automatically. A third was a message handler that accepted commands from the webview without checking them. The fourth was a file-write function that took any address, with no limit on where it could point. Four further CVE numbers now cover those issues, alongside the original eval flaw.

Each of the four extra bugs mattered on its own. Together, they turned one weak link into a full chain. The sandbox escape meant a codebase with no WaveDrom diagrams was not automatically safe. A malicious project configuration file could reach the same outcome a different way. The template injection flaw let an attacker’s script persist across sessions, instead of needing a fresh trigger each time. The unchecked message handler and the unrestricted file writer mattered most of all. Together they turned code execution inside a webview into control over files on the host. That is the step that makes this a genuine supply chain concern, not just a bug in a preview pane.

How the fix rolled out

The maintainer moved fast once notified. Version 0.8.28 came out on 5 June. It replaced the dangerous eval() call with a safe JSON parser. A day later, version 0.8.29 arrived. It swapped the extension’s script sandbox for an isolated JavaScript engine that cannot touch the host system. By 8 June, version 0.8.30 closed the remaining three issues. It added input validation and a strict allow list for webview commands. This VS Code extension vulnerability took three point releases and four days to fully close. Anyone running an older build should update now; the current release carries none of the reported flaws.

Not the first disclosure against this extension

This is not the extension’s first brush with security researchers. Back in February, a separate team at OX Security flagged an earlier, unrelated flaw in the same extension. They also found issues in three other popular VS Code add-ons, together installed more than 125 million times. Their conclusion applies just as well here. An attacker needs only one vulnerable extension to move sideways through an organisation, once a single developer machine is compromised.

Why this belongs on a business risk register

Editor extensions rarely get the scrutiny that production code receives. They run with the same file access as the developer using them, and they install with a single click. Updates happen silently in the background. Few security teams treat an IDE plug-in as part of the attack surface, yet this VS Code extension vulnerability shows one can. It can give an attacker a foothold on a machine with direct access to source repositories and deployment credentials.

Businesses that rely on developers using VS Code should treat this as a reminder. Review what extensions are installed across the estate, not just what patches are outstanding. A quick inventory now costs far less than cleaning up after a compromised build pipeline later.

There is also a practical lesson in how this disclosure was handled. ProjectDiscovery reported the issues privately, gave the maintainer time to respond, and published only after fixes were live. That is the coordinated process that limits real-world exploitation. It does not mean the risk window was zero, though. Anyone who had not updated between the fix landing and today remains exposed. The researchers’ technical write-up now gives any attacker a detailed roadmap for building an exploit against unpatched installs.

What to do next

• Confirm Markdown Preview Enhanced is on version 0.8.30 or later across every developer machine. Remove it if it is not needed.
• Ask whether your organisation keeps an inventory of installed IDE and browser extensions. Most patch management processes skip them entirely.
• Treat developer endpoints as high-value targets in any internal penetration test, given their access to code, credentials and build systems.
• Watch for further disclosures against widely installed extensions. This VS Code extension vulnerability is unlikely to be the last one found this year.