CVE-2025-65715 leaves users of the Code Runner extension for Visual Studio Code exposed to arbitrary command execution when a crafted
OX Security disclosed the flaw in February, describing a configuration-driven route to code execution rather than a vulnerability in a language runtime or the VS Code editor itself. That distinction matters: Code Runner is built to execute developer-defined commands, but its configuration surface can turn a seemingly routine workspace or settings change into an attacker-controlled shell command.
For Windows developers, the practical impact is straightforward. A poisoned Code Runner configuration can execute under the permissions of the signed-in user when that user invokes Run Code on a matching file. That can mean PowerShell,
Code Runner is a popular utility extension from publisher formulahendry, designed to run a source file or selected snippet without making developers configure a task or debug launch profile. It supports a long list of languages and exposes settings that map language identifiers to executable commands.
Its
The same flexibility is the problem. According to OX Security’s technical analysis, Code Runner reads a command string from
That is why this is classified as CWE-94, improper control of code generation, rather than a conventional memory-safety bug. The extension accepts a command as configuration, then treats it as executable instruction.
On Windows, an attacker does not need OX Security’s Linux-oriented reverse-shell demonstration to make the flaw relevant. A malicious executor mapping can be constructed around Windows-native command interpreters and utilities. The result remains code execution in the developer’s own context—not administrator by default, but potentially enough to access source trees, local tokens, SSH keys, cloud CLI credentials, browser data, and corporate network resources available to that account.
The important qualification is user interaction. CISA’s vector records a local attack vector with user interaction required. In the ordinary scenario, an attacker needs the victim to open or trust a workspace and then run code through Code Runner, or needs another locally installed extension to modify configuration first. This is serious, but it is not evidence that simply receiving a repository causes immediate execution in a properly restricted VS Code session.
Microsoft’s Workspace Trust model is a meaningful mitigation layer. VS Code opens unfamiliar folders in Restricted Mode, limiting workspace settings, terminal behavior, extensions, debugging, and other execution-capable features. The Code Runner setting is declared at the resource scope, meaning it can be supplied from workspace-level configuration; treating an unfamiliar repository as trusted removes an important guardrail.
Workspace Trust does not eliminate the risk from global settings. OX Security’s report notes that a malicious edit to the user-level
The correct framing is that VS Code reduces exposure to untrusted project configuration, while Code Runner’s design gives a modified configuration unusually direct access to the local shell after a developer elects to execute code.
As of July 19, neither the NVD entry nor the Code Runner project repository identifies a fixed release. The live project metadata still lists version 0.12.2, and the public source continues to show the configuration-derived command reaching
That does not prove that every Marketplace package or downstream fork is identical, nor should administrators treat a source-code snapshot as a formal vendor statement. It does mean there is no clearly documented upgrade target that teams can rely on as remediation. Updating VS Code alone does not change the vulnerable Code Runner command-handling logic.
For organizations that permit extension use on developer endpoints, that turns this from a patch-management exercise into an exposure-management decision.
Administrators should inventory
A focused response should include:
code-runner.executorMap setting is applied and code is run. The issue carries a CVSS 3.1 score of 7.8, rated High by CISA’s vulnerability-enrichment program, and it affects Code Runner 0.12.2—the version still reflected in the project’s source metadata as of July 19, 2026.OX Security disclosed the flaw in February, describing a configuration-driven route to code execution rather than a vulnerability in a language runtime or the VS Code editor itself. That distinction matters: Code Runner is built to execute developer-defined commands, but its configuration surface can turn a seemingly routine workspace or settings change into an attacker-controlled shell command.
For Windows developers, the practical impact is straightforward. A poisoned Code Runner configuration can execute under the permissions of the signed-in user when that user invokes Run Code on a matching file. That can mean PowerShell,
cmd.exe, a downloaded payload, credential theft from the user profile, or persistence through normal Windows user-level mechanisms.
The Dangerous Setting Is Also a Core Feature
Code Runner is a popular utility extension from publisher formulahendry, designed to run a source file or selected snippet without making developers configure a task or debug launch profile. It supports a long list of languages and exposes settings that map language identifiers to executable commands.Its
code-runner.executorMap setting is intended to make execution flexible. A developer can point Python at a particular interpreter, invoke a compiler before running a C++ binary, or substitute a custom runtime. The repository documentation explicitly shows command chains such as changing directories, compiling code, and launching the resulting executable.The same flexibility is the problem. According to OX Security’s technical analysis, Code Runner reads a command string from
executorMap, expands placeholders such as a file name or directory, then invokes Node.js child_process.spawn() with shell: true. In the output-panel execution path, the command is handed to the operating system shell without a safety boundary that distinguishes an expected interpreter command from appended shell syntax.That is why this is classified as CWE-94, improper control of code generation, rather than a conventional memory-safety bug. The extension accepts a command as configuration, then treats it as executable instruction.
On Windows, an attacker does not need OX Security’s Linux-oriented reverse-shell demonstration to make the flaw relevant. A malicious executor mapping can be constructed around Windows-native command interpreters and utilities. The result remains code execution in the developer’s own context—not administrator by default, but potentially enough to access source trees, local tokens, SSH keys, cloud CLI credentials, browser data, and corporate network resources available to that account.
A Crafted Workspace Is Not the Same as a Drive-By Attack
The National Vulnerability Database describes CVE-2025-65715 as arbitrary code execution throughcode-runner.executorMap when opening a crafted workspace. OX Security also outlined two likely delivery routes: social engineering that persuades a developer to paste configuration into settings.json, and a malicious or compromised extension that alters settings.The important qualification is user interaction. CISA’s vector records a local attack vector with user interaction required. In the ordinary scenario, an attacker needs the victim to open or trust a workspace and then run code through Code Runner, or needs another locally installed extension to modify configuration first. This is serious, but it is not evidence that simply receiving a repository causes immediate execution in a properly restricted VS Code session.
Microsoft’s Workspace Trust model is a meaningful mitigation layer. VS Code opens unfamiliar folders in Restricted Mode, limiting workspace settings, terminal behavior, extensions, debugging, and other execution-capable features. The Code Runner setting is declared at the resource scope, meaning it can be supplied from workspace-level configuration; treating an unfamiliar repository as trusted removes an important guardrail.
Workspace Trust does not eliminate the risk from global settings. OX Security’s report notes that a malicious edit to the user-level
settings.json can persist across workspaces, letting a poisoned executor mapping survive after the original project is closed. Nor does Workspace Trust defend against an already-installed malicious extension that is permitted to write user settings.The correct framing is that VS Code reduces exposure to untrusted project configuration, while Code Runner’s design gives a modified configuration unusually direct access to the local shell after a developer elects to execute code.
No Verified Vendor Fix Is Evident
The advisory’s chronology is unusually awkward. OX Security said it reported the broader set of extension issues in 2025, but its public CVE post appeared on February 17, 2026. The NVD published the CVE entry on February 16, 2026, and last modified it on June 17, 2026.As of July 19, neither the NVD entry nor the Code Runner project repository identifies a fixed release. The live project metadata still lists version 0.12.2, and the public source continues to show the configuration-derived command reaching
spawn(command, [], { cwd, shell: true }). Third-party reporting, including a SecPod advisory, has similarly described the vulnerability as unpatched.That does not prove that every Marketplace package or downstream fork is identical, nor should administrators treat a source-code snapshot as a formal vendor statement. It does mean there is no clearly documented upgrade target that teams can rely on as remediation. Updating VS Code alone does not change the vulnerable Code Runner command-handling logic.
For organizations that permit extension use on developer endpoints, that turns this from a patch-management exercise into an exposure-management decision.
The Immediate Response Is to Remove the Execution Surface
Teams that do not need Code Runner should uninstall or disable it rather than wait for a promised update. Developers who use it occasionally should avoid opening unfamiliar projects with it enabled, keep those projects in Restricted Mode, and use explicit build tasks, vetted scripts, or a disposable development environment when evaluating untrusted code.Administrators should inventory
formulahendry.code-runner across managed VS Code installations and inspect user and workspace settings for unexpected code-runner.executorMap, executorMapByGlob, executorMapByFileExtension, and customCommand entries. A command mapping that includes unrelated shell chaining, remote retrieval, encoded PowerShell, or paths outside an approved toolchain deserves immediate investigation.A focused response should include:
- Remove or disable Code Runner on endpoints where it is not operationally required.
- Review global VS Code settings, not only repository
.vscode/settings.jsonfiles. - Enforce Workspace Trust and avoid broad trusted parent folders that automatically trust newly cloned repositories.
- Restrict unapproved extensions and monitor changes to VS Code user configuration directories.
- Treat unexpected changes to interpreter or executor mappings as endpoint-security events, especially on developer workstations with production credentials.
References
- Primary source: ox.security
Published: 2025-11-27T07:55:30+00:00
CVE-2025-65715: Code Runner VS Code RCE Vulnerability
Technical Analysis of CVE-2025-65715: high-severity vulnerability in the Code Runner VS Code extension that enables remote code executionwww.ox.security - Official source: github.com
/bin/sh: ts-node: command not found · Issue #162 · formulahendry/vscode-code-runner · GitHub
I have already install ts-node. I did not do any setting up.
github.com
- Related coverage: marketplace.visualstudio.com
Code Runner - Visual Studio Marketplace
Extension for Visual Studio Code - Run C, C++, Java, JS, PHP, Python, Perl, Ruby, Go, Lua, Groovy, PowerShell, CMD, BASH, F#, C#, VBScript, TypeScript, CoffeeScript, Scala, Swift, Julia...marketplace.visualstudio.com
