Malicious VS Code Extensions at Work: How Security Teams Detect, Block, and Respond

VS Code extensions run with the full permissions of the user who launched VS Code. Unlike browser extensions, which are sandboxed and have a declared permissions model, VS Code extensions can read and write any file accessible to the user, make arbitrary network connections, spawn child processes, read environment variables including secrets, and access the git credential store.

An extension installed on a developer machine has access to:

• Source code across all open workspaces
• Environment variables including AWS_ACCESS_KEY_ID, GITHUB_TOKEN, and any secrets loaded by dotenv
• The ~/.ssh directory including private keys
• The ~/.aws/credentials file
• Git configuration including stored credentials
• Any secrets manager CLI credentials cached in memory

The attack surface is compounded by the fact that extensions auto-update silently by default. An extension that was benign when a developer installed it can deliver malicious code in a subsequent update without any user interaction.

VS Code stores installed extensions in a predictable location. On macOS and Linux: ~/.vscode/extensions/. On Windows: %USERPROFILE%.vscode\extensions. Each extension is a directory named publisher.extension-version.

For fleet-wide auditing, deploy a script via your MDM (Jamf, Intune, Workspace ONE) or configuration management tool (Ansible, Chef) that reads this directory on each machine and ships the list to a central location.

A simple audit script for macOS/Linux:

ls ~/.vscode/extensions/ | awk -F'-' '{NF-=1; print}' OFS='-' | sort -u

For Windows via PowerShell:

Get-ChildItem "$env:USERPROFILE\.vscode\extensions" -Directory | 
  Select-Object -ExpandProperty Name

Once you have the list, cross-reference it against your approved extension allowlist. Any extension not on the allowlist is a finding. Prioritize reviewing extensions with access to network (any extension that makes outbound requests) and extensions with access to the file system.

VS Code supports an extensions.allowedExtensionIDs setting in managed configuration. When set, VS Code will only activate extensions in the allowlist, other installed extensions are disabled at launch.

Deploy this via your MDM as a managed VS Code configuration file. On macOS with Jamf, push a configuration profile that writes to /Library/Application Support/Code/User/settings.json (the machine-level settings file). On Windows with Intune, use a PowerShell script to write the setting to the machine-level settings path.

Example managed settings.json:

{
  "extensions.allowedExtensionIDs": [
    "ms-python.python",
    "ms-vscode.cpptools",
    "dbaeumer.vscode-eslint"
  ],
  "extensions.autoUpdate": false,
  "extensions.autoCheckUpdates": false
}

Disabling auto-updates (extensions.autoUpdate: false) is critical, it prevents silent malicious updates to approved extensions. Pair this with a review process for approving extension updates before pushing them to the managed allowlist.

Even with allowlists, the detection layer matters. A compromised allowlisted extension needs to be caught at runtime. Look for these behavioral indicators in your EDR:

Unexpected outbound connections from Code Helper: On macOS, VS Code extensions run in the Code Helper (Plugin) process. Alert on outbound connections from this process to non-approved destinations, especially newly registered domains, residential proxy networks, or cloud storage endpoints not in your approved list.

File access outside the workspace: Extensions operating normally access files within the workspace root. Alert on Code Helper reading ~/.ssh/, ~/.aws/credentials, ~/.npmrc, or ~/.gitconfig outside of a workspace directory.

Child process spawning: Some extensions legitimately spawn child processes (linters, formatters), but alert when Code Helper spawns processes that make outbound network connections, especially curl, wget, python, or node executing scripts from temp directories.

Environment variable enumeration: An extension reading the full process environment (all variables) rather than a specific known variable is a behavioral anomaly. Some EDR platforms (CrowdStrike, SentinelOne) can detect this via API call monitoring.

If you identify a malicious extension on a developer machine, treat it as a full credential compromise. The extension had code execution; assume everything accessible to that user's session is compromised.

Immediate actions in order:

1. Isolate the machine from the network via your EDR (CrowdStrike RTR, SentinelOne Remote Script). Do not ask the developer to do this manually.
2. Revoke all cloud credentials that could have been accessed: AWS IAM access keys and session tokens, GitHub PATs and SSH keys, npm tokens, any secrets in environment variables.
3. Pull the VS Code extension logs from the machine before isolation if possible: ~/.vscode/extensions/[malicious-extension]/ and the VS Code developer console logs.
4. Check what the extension had access to: the git log of every repository open in VS Code at the time, the list of workspace folders, and the environment variables in the user's shell profile.
5. Review your extension allowlist and determine how the malicious extension was present, whether it was on the allowlist, whether it was a compromised update of an allowlisted extension, or whether the allowlist control was not yet enforced on this machine.

A one-time audit does not scale. The controls that keep extension risk manageable over time:

Extension change monitoring: Deploy a daily cron job on developer machines that diffs the current extension list against the last known state and alerts on new additions. A new extension appearing on a machine that is not in the managed configuration is an immediate finding.

Supplier monitoring for approved extensions: Subscribe to security advisories for every extension on your allowlist. The VS Code marketplace does not have an API for security advisories, but most popular extensions have GitHub repositories, watch their release notes and the VS Code marketplace publisher account for unexpected activity.

Extension publisher verification: Before approving a new extension, check the publisher's GitHub profile age, the extension's source code repository (many extensions do not publish source), the extension's install count history (a sudden spike in installs of a previously unknown extension is a red flag), and whether the publisher account was recently transferred.