How Your Code Editor Can Become a Security Risk

Modern dev environments are incredibly powerful, but that power hides a risk we usually overlook: the extensions we use every day.

Today, I came across a blog post from OX Security that highlights a huge gap in how we think about our workstations. The report outlines how vulnerabilities in popular extensions can lead to remote code execution and local file exfiltration. This does not just affect software engineers. Any professional using an IDE for scripting or automation operates within this vulnerable area.

You can read the full report here:
https://www.ox.security/blog/four-vulnerabilities-expose-a-massive-security-blind-spot-in-ide-extensions/

The Trust Problem

Personally, I’ve been using VS Code for several years and don’t see myself switching to another IDE anytime soon. Part of that is familiarity and comfort because it feels local and implicitly trusted. It’s where I explore code, test ideas, build, break, and fix things🙂. From a security perspective, however, many of the extensions we rely on run with significant privileges and can access:

• Our local source code and build artifacts.

• Environment variables and config files.

• API tokens, SSH keys, and cloud credentials.

These components often bypass formal review processes. Extensions are installed ad hoc, updated automatically, and rarely audited. The OX Security research shows how this trust model breaks down, even for extensions with massive install counts and reputable publishers.

The issue is not that extensions are inherently unsafe but that we treat it differently from other dependencies, despite the level of access it has.

---

What the Report Shows

One of the more uncomfortable findings in their blog is that even popular extensions with tens of millions of installs aren’t automatically safe.

The vulnerabilities described include:

• Remote code execution via extension exposed services

• Local file exfiltration triggered by crafted inputs

• Insecure assumptions about where data originates

These attacks take advantage of IDE extensions having local access while also connecting to the network, without the same security hardening used for backend services.

---

Visibility Is the Real Problem

This is not about blaming devs or discouraging useful tooling. In most teams, extensions are installed with good intentions and rarely revisited.

The real issue is visibility:

• Do we know which extensions are installed across dev machines?

• Are we aware of what permissions it has?

• Do we have any process to review or reassess it over time?

For many teams, IDE extensions are not centrally tracked or audited, and they can occupy a grey area that existing security processes may not fully cover.

---

Listing Installed VS Code Extensions on macOS

If you want to audit extensions, the first step is simply knowing what is installed.

On macOS, you can list all your VS Code extensions by running:

ls ~/.vscode/extensions

Each directory follows this format:

publisher.extension-version

Important: Only include the Extension ID and NOT the version number

Extension scanning and auditing tools, such as VSCan, expect the extension ID in the following format otherwise the tool will not recognise it:

publisher.extension #nothing else

To extract clean extension IDs on macOS, run this in your terminal:

for dir in ~/.vscode/extensions/*; do
  name=$(basename "$dir")
  echo "${name%-*}"
done

This list can then be used for:

• Manual review – Check if extensions like ms-python.python or eamodio.gitlens are really needed, and remove any that are unused.

• Feeding into scanning tools – tools such as VSCan can analyse each extension for risky behaviours or suspicious permissions.

• Comparing against advisories or reports – See if installed extensions match those flagged in vulnerability reports, such as the OX Security blog highlighting Live Server or Markdown Preview Enhanced.

• Staying informed – Devs should consider following sources like The Hacker News, security blogs, and advisory feeds to stay up to date on new extension vulnerabilities and patches.

Here’s an example of the output you can expect to see from VSCan:

Keep in mind that flagged risks are contextual: even actively maintained extensions can carry exposure depending on local configuration, access to sensitive files, or network connectivity. So the risk changes depending on how and where you use the extension.

---

Auditing Extensions Without Overengineering

Unlike server side libraries or OS packages, IDE extensions lack a dedicated, comprehensive vulnerability database. That makes traditional dependency scanning insufficient on its own.

If your organisation currently lacks a formal process for this, one option worth exploring is VSCan, which focuses specifically on analysing IDE extensions for risky behaviours and known red flags. It helps move from “I hope this extension is safe” to “I know what this extension does and the risks it carries.

You can then consider combining it with a lightweight policy such as:

• Periodic extension reviews to ensure only necessary tools are installed

• Removing unused extensions to minimise the attack surface

• Prioritise extensions that are well-maintained or provided by verified publishers

This can significantly reduce unnecessary exposure without slowing down development.

---

A Small Shift in How We Think

The broader lesson from this is simple but important. Treating IDE extensions with the same curiosity and caution we apply to other dependencies doesn’t require a heavy, restrictive process. It starts with awareness, visibility, and the willingness to ask a basic question:

Do we actually know what is running on our machines?

Whether you are building an app, training a data model, or managing infrastructure, your editor is a critical part of your software supply chain. Its time we treat it that way.🙂