When Opening Code Becomes Running Code: Inside CVE-2025-68120 and the Hidden Risk in Developer Tools

A Deep Dive into the Visual Studio Code Go Extension Vulnerability

Developer tools are often treated as trusted companions—helpers that make writing, testing, and reviewing code easier. But what happens when one of those tools quietly steps outside the security boundaries it’s supposed to respect?

That question sits at the heart of CVE-2025-68120, a vulnerability in the Visual Studio Code Go extension that exposed developers to unintended code execution when working with untrusted projects. While this issue doesn’t involve a flashy zero-click exploit or a remote attacker instantly taking over systems, it highlights a much more subtle and dangerous problem: the erosion of trust guarantees inside the development environment itself.

This article walks through what happened, why it matters, how it could be abused, and what organizations and developers should take away from it.

The Big Picture

CVE-2025-68120 affects the Go extension for Visual Studio Code, a widely used add-on that provides Go language support such as linting, formatting, testing, and code navigation.

The vulnerability arose because the extension did not fully honor VS Code Restricted Mode, a built-in security feature designed to protect developers when they open code from unknown or untrusted sources. In certain situations, the Go extension could still execute Go-related commands automatically—even though the workspace was explicitly marked as untrusted.

In short:
Opening untrusted code could still result in code execution.

That is a serious violation of the trust model developers rely on.

Understanding Restricted Mode

Restricted Mode exists for one simple reason:

Looking at code should not be the same as running code.

When a developer opens a project downloaded from the internet, cloned from a public repository, or shared by someone else, Visual Studio Code treats it as untrusted. In this mode:

Extensions are limited in what they can do
Automatic execution of tools should be blocked
Potentially dangerous actions require explicit user trust

This model is critical because developers routinely inspect unfamiliar code—pull requests, samples, tutorials, or third-party repositories. Restricted Mode is the safety net that makes this behavior reasonably safe.

CVE-2025-68120 weakened that net.

What Went Wrong in the Go Extension

The Go extension is tightly integrated with the Go toolchain. To deliver features developers expect, it routinely runs commands such as:

go list
go build
Linters and formatters
Dependency resolution tools

Before the fix, the extension did not consistently verify whether the workspace was trusted before performing these actions. As a result, it could:

Read workspace-specific configuration files
Honor custom tool paths defined by the project
Execute binaries referenced in those configurations

All of this could happen automatically, during extension initialization, without the developer clicking “Trust”.

This wasn’t a single coding mistake—it was a design gap, where extension behavior evolved faster than the surrounding security model.

How This Could Be Exploited

This vulnerability is best understood as a developer-targeted attack vector.

A Realistic Attack Flow

Preparation
An attacker creates a Go project that includes a .vscode/settings.json file. Inside, they specify custom Go tools—linters or formatters—that point to malicious binaries.
Distribution
The project is shared as:
- An open-source repository
- A demo or tutorial
- A pull request
- A sample project in a forum or chat
Workspace Opened
A developer opens the project in Visual Studio Code. The editor correctly marks it as untrusted and enables Restricted Mode.
Unexpected Execution
Despite Restricted Mode, the vulnerable Go extension initializes and runs the configured tools. The malicious binaries execute automatically.
Impact
The payload now runs in the developer’s user context and can:
- Read environment variables containing API keys
- Access cloud credentials or SSH keys
- Exfiltrate source code
- Install persistence mechanisms
- Modify other projects on the machine

Nothing “breaks out” of VS Code. Instead, the extension walks straight through a boundary that was assumed to be closed.

Why This Matters More Than It First Appears

On paper, CVE-2025-68120 requires user interaction and doesn’t spread on its own. But developer machines are uniquely valuable targets:

They often hold credentials for production systems
They have access to source code repositories
They may have signing keys, tokens, or secrets cached locally
They sit upstream in the software supply chain

A single compromised developer workstation can lead to:

Intellectual property theft
Supply chain compromise
Unauthorized access to cloud infrastructure

This is why vulnerabilities in IDEs and extensions deserve the same seriousness as server-side flaws.

Detection and Monitoring Considerations

Organizations looking to identify potential abuse should focus on behavior, not signatures.

Key signals include:

Visual Studio Code spawning Go processes immediately after opening an untrusted workspace
Go tools executing from temporary directories or project folders instead of standard system paths
Unexpected outbound network connections originating from VS Code or its child processes
Access attempts to sensitive files such as SSH keys or cloud credential stores

Process creation logs, endpoint detection tools, and network telemetry are the most valuable data sources for spotting this activity.

The Fix and Why It’s Important

The maintainers of the Go extension addressed the issue decisively. Instead of trying to selectively block individual actions, they chose a fail-secure approach:

The Go extension is now disabled entirely in Restricted Mode
No Go CLI commands are executed until the workspace is explicitly trusted

This change was released in:

v0.52.1 and later (stable)
v0.53.0 and later (pre-release)

This approach removes ambiguity and ensures that Restricted Mode actually means what developers think it means.

What Developers and Organizations Should Do

Immediate Actions

Ensure all developer machines are running patched versions of the Go extension
Encourage developers to pay attention to workspace trust prompts
Avoid opening untrusted code in environments with sensitive credentials

Long-Term Practices

Treat IDEs and extensions as security-critical software
Minimize installed extensions to reduce attack surface
Use isolated environments (containers or virtual machines) for reviewing unknown code
Provide training on modern supply chain and developer-focused attacks

A Broader Lesson for the Industry

CVE-2025-68120 is not just about Go or Visual Studio Code. It’s a reminder that:

Security boundaries inside developer tools are just as important as firewalls and access controls in production systems.

The Go extension team’s response shows the right mindset: when trust is unclear, disable first and enable only when explicitly allowed.

As development environments grow more powerful and automated, maintaining strict trust enforcement will be essential to protecting the software supply chain.

Final Takeaway

This vulnerability didn’t cause headlines because it wasn’t flashy. But its implications are far-reaching. Developers are high-value targets, and IDEs are powerful execution platforms. When trust boundaries fail silently, attackers don’t need exploits—they just need opportunity.

Keeping tools updated, respecting trust warnings, and understanding how your development environment behaves under the hood are no longer optional habits. They are core security practices.

If there’s one takeaway from CVE-2025-68120, it’s this:

The security of your code starts with the security of the tools you use to write it.