TL;DR

Your developers' IDE is now a primary attack vector. The GlassWorm campaign has deployed 73 sleeper extensions across Open VSX that are now actively delivering credential-stealing malware to VS Code, Cursor, and Windsurf installations. Wiz Research independently found 550+ live secrets — including publisher access tokens (PATs) covering 185,000+ installs — embedded directly in marketplace extension packages. Two unpatched Cursor sandbox escapes (CVE-2026-31854, CVE-2026-26268) give attackers code execution from malicious extensions before any EDR can respond.

The attack surface is the developer workstation, and the delivery mechanism bypasses every traditional perimeter control. This playbook gives you the complete detection, response, and hardening strategy.

---

Background: The IDE Became the Perimeter

Through 2020-2024, attackers treated package managers (npm, PyPI) as the primary developer supply chain vector. The IDE itself was largely ignored — a safe-harbor tool sitting behind corporate firewalls, loaded with extensions from curated marketplaces.

That mental model is now obsolete.

Three developments converged in early 2026 to transform the IDE into a first-class attack surface:

1. AI-powered IDE adoption exploded. VS Code forks — Cursor, Windsurf, Void — gained millions of developer seats in 18 months. These forks rely on Open VSX (open-vsx.org) as their extension marketplace, a community-run registry with weaker publisher verification than Microsoft's VS Code Marketplace.

2. Extensions gained API-agent privileges. Modern AI IDEs grant extensions access to LLM contexts, MCP server connections, ambient file system reads, and terminal execution. A malicious extension in 2026 has capabilities that a malicious npm package from 2022 could only dream of — including the ability to intercept AI coding agent outputs before they reach the developer.

3. Marketplace security review is a fiction. Both the VS Code Marketplace and Open VSX rely on post-publication automated scanning plus community reports. GlassWorm defeated this by publishing clean extensions that pass all automated scans, then weaponizing them via a software update weeks later — after install counts have risen and reputation has been established.

---

Technical Analysis

GlassWorm Phase 1: The March 2026 Dependency Abuse Wave

The first GlassWorm cluster, documented by Socket in March 2026, used extension dependency hijacking: publishing legitimate-looking extensions that declared malicious hidden packages as dependencies. When a developer installed the extension, the package manager silently pulled the malicious dependency without any marketplace scan touching it.

The March cluster used 72 extensions targeting Open VSX specifically — chosen because Open VSX allows community publishers without verified organizational identities, unlike Microsoft's stricter identity requirements for the VS Code Marketplace.

Payload: a loader that exfiltrated environment variables, shell history, SSH agent sockets, and .env files to an attacker-controlled endpoint. Targeting: developers with AWS, GCP, OpenAI, and GitHub credentials visible in their environment.

GlassWorm Phase 2: April 2026 — The Sleeper Cluster

The April cluster of 73 extensions represents a tactical evolution:

Impersonation over dependency abuse. Instead of legitimate extensions with malicious dependencies, attackers used newly created GitHub accounts to publish cloned versions of popular extensions — pixel-perfect copies with publisher name swaps. The most documented example: a fake "Turkish Language Pack" with identical globe icon, description, and install flow, but a different publisher identity.

Thin loaders, external payloads. The malicious code is no longer embedded in the extension's source at time of submission. The extension contains only a minimal loader that fetches the actual payload from an external URL after installation. This defeats static analysis scanning entirely.

Two primary execution mechanisms observed:

• postinstall script hooks executing JavaScript at install time
• VS Code/Open VSX extension activation events that fire on IDE launch, calling child_process.exec() with remotely-fetched commands

Sleeper timing. At least 6 of the 73 April extensions had already "activated" (pushed weaponized updates) by the time Socket published its report. The remaining 67 were still in sleeper mode — clean, accumulating installs, waiting for the operator to flip the switch.

The PAT Hijacking Amplifier

Wiz Research's October 2025 investigation (published findings now actively exploited in 2026) adds a catastrophic amplifier to this picture.

When a publisher creates a VS Code Marketplace or Open VSX extension, they authenticate via a Personal Access Token (PAT). Wiz found that publishers routinely hardcode these PATs directly into their .vsix extension packages — which are simply ZIP files, publicly downloadable by anyone.

The numbers:

• 550+ validated secrets found across 500+ extensions
• 100+ valid VS Code Marketplace PATs with active update permissions → 85,000+ installs exposed
• 30+ valid Open VSX access tokens → 100,000+ installs exposed
• Secret categories: AI provider keys (OpenAI, Anthropic, Gemini), AWS/GCP/GitHub tokens, database credentials (MongoDB, Postgres, Supabase)

An attacker who finds a leaked publisher PAT can push a malicious update to every existing install of that extension — silently, immediately, via the same auto-update mechanism users trust. Microsoft is implementing platform-level mitigations, but as of April 2026, tens of thousands of extensions have not been remediated.

Cursor-Specific CVEs: The AI IDE Attack Surface

Cursor specifically has shipped two CVEs that give attackers a foothold even when extension review is tight:

CVE-2026-26268 (CVSS 8.1, patched Feb 2026): Sandbox escape via writing .git/config. An attacker with malicious extension control could escape Cursor's extension sandbox by injecting a malicious core.fsmonitor hook into .git/config, which Cursor's process would then execute. Affected versions: pre-0.45.

CVE-2026-31854 (CVSS 9.0, patched March 2026): Remote code execution via the extension API's HTTP request handler. An extension could invoke the Cursor-specific cursorRequest API to exfiltrate data or execute shell commands, bypassing the standard VS Code extension permission model. Affected versions: pre-0.47.

Both CVEs require an installed malicious extension as the initial vector — which is exactly what GlassWorm provides.

---

IOCs / Indicators

GlassWorm Campaign April 2026:

• Publisher pattern: newly registered GitHub accounts (< 30 days) with single-purpose profiles
• Extension names: clones of top-50 Open VSX extensions (language packs, themes, linters, formatters)
• Loader behavior: HTTP GET to domains matching pattern cdn-[a-z]{6}\.(workers\.dev|pages\.dev|vercel\.app) within 60 seconds of extension activation
• File writes: .config/glassworm/ directory creation in user home
• Process spawns: node spawning sh -c with base64-encoded arguments within VS Code / Cursor process tree

PAT Hijacking Pattern:

• Look for extensions with OVSX access tokens or Azure DevOps PATs in .vsix bundle inspection
• Tool: npx @wiz-sec/vscode-secret-scanner <extension.vsix>

Network IOCs (observed GlassWorm C2):

• cdn-xkpqrt.workers.dev
• api-update.pages.dev
• ext-cdn.vercel.app (generic pattern; many legitimate uses exist — correlate with process ancestry)

---

Lyrie Take

The IDE is now the riskiest privileged process on a developer workstation — and most organizations have zero controls on it.

Think about what the IDE process legitimately does: reads every source file, executes code via terminals, connects to cloud APIs, authenticates to GitHub, holds AI model API keys in environment variables, and in 2026 runs autonomous AI agents that can make API calls and write to production systems. A malicious extension inherits all of that without triggering any EDR alert, because the VS Code or Cursor process is explicitly trusted.

The GlassWorm sleeper model is particularly dangerous because it defeats the only defense most organizations rely on: "we installed it a month ago and nothing happened." The extension was designed to pass that test. The weapon arrives months before the trigger is pulled.

What makes this an autonomous-defense problem: by the time a human analyst sees the anomalous process spawn from VS Code, the credential exfiltration has already completed. Machine-speed detection at the OS process spawn and network call layer — correlated with extension activity events — is the only response path that arrives before the payload executes.

---

Defender Playbook

Step 0 — Immediate Triage (Do This Now)

# Audit installed extensions across developer fleet (VS Code)
code --list-extensions > installed-extensions.txt

# For Cursor
~/.cursor/extensions/ # enumerate directories

# Cross-reference against Socket's GlassWorm blocklist
curl -s https://socket.dev/blog/glassworm-april-2026-ioc-list.json | \
  jq '.blocked_extensions[]' > glassworm-blocked.txt

diff installed-extensions.txt glassworm-blocked.txt

For any match: Revoke all developer credentials (GitHub, cloud provider, AI API keys) immediately. Treat the workstation as compromised. Rotate secrets before removing the extension.

---

Step 1 — Extension Policy Enforcement

Enterprise VS Code: Use extensions.json allowlisting

VS Code supports workspace-level extension recommendations, but enterprise enforcement requires the extensions.allowedExtensionIDs policy via Group Policy (Windows) or MDM profile (macOS/Linux):

// /etc/vscode/policy.json (Linux MDM) or via Intune/Jamf
{
  "extensions.allowedExtensionIDs": [
    "ms-python.python",
    "esbenp.prettier-vscode",
    "dbaeumer.vscode-eslint"
    // ... explicit allowlist only
  ]
}

For Cursor and other forks: no built-in enterprise policy exists yet. Use filesystem-level controls:

• Block write access to ~/.cursor/extensions/ via Endpoint DLP
• Require extension installation via a proxy (see Step 3)

Critical: Disable auto-updates in enterprise environments

// settings.json
{
  "extensions.autoUpdate": false,
  "extensions.autoCheckUpdates": false
}

Every extension update should go through the same review process as the initial install. Auto-update is the PAT hijacking delivery vector.

---

Step 2 — EDR Behavioral Rules

Add detection for the following process behavior chains to your EDR policy:

Rule 1: IDE Spawning Encoded Shell Commands

parent_process: ["Code", "Cursor", "cursor", "Windsurf"]
child_process: ["sh", "bash", "zsh", "cmd.exe", "powershell.exe"]
command_line contains: ["base64", "eval", "-e ", "fromBase64"]

Rule 2: IDE Making Outbound Connections to Non-Allowlisted Hosts

parent_process: ["Code", "Cursor"]
network_connection: NOT IN [known_CDNs, known_package_registries]
bytes_out: > 10KB
time_after_process_start: < 300s

Rule 3: Extension Directory Modification During Runtime

path: [~/.vscode/extensions/, ~/.cursor/extensions/]
operation: [file_create, file_modify]
initiating_process: NOT ["Code", "code-helper", "cursor"]

Rule 4: Credential File Access by IDE Process

process: ["Code", "Cursor"]
files_read: ["~/.aws/credentials", "~/.ssh/id_rsa", ".env", "*.pem", "*.key"]
AND command_line NOT contains legitimate_extension_names

---

Step 3 — Extension Proxy / Vetting Pipeline

Do not let developers install extensions directly from open-vsx.org or marketplace.visualstudio.com without review:

1. Stand up an internal Open VSX mirror using OpenVSX self-hosted or JFrog Artifactory VSCode plugin.

2. Gate all extension installs through the mirror. Block direct outbound connections to open-vsx.org and marketplace.visualstudio.com at the firewall.

3. Vetting process for new extension requests:

- Publisher age check: reject publishers with < 90-day history

- Install count threshold: require > 10,000 installs or organizational sign-off

- PAT scan: npx @wiz-sec/vscode-secret-scanner on the downloaded .vsix

- VirusTotal + Socket.dev analysis of the bundle

- Behavioral sandbox: run in isolated VM, monitor network calls and file system writes for 5 minutes post-activation

4. Approved extensions get pinned to specific versions in the mirror. Updates require re-vetting.

---

Step 4 — Secret Hygiene in Extension Development

If your organization publishes VS Code extensions (internal tools, customer-facing):

• Scan .vsix before publishing: npx @wiz-sec/vscode-secret-scanner ./my-extension.vsix
• Add to CI/CD: run the scanner as a required step before any marketplace publish
• Rotate PATs on a 90-day cycle via your CI/CD secrets manager; never hardcode them
• Use environment-scoped PATs with the minimum permission set (publish-only, not admin)
• If you discover a leaked PAT: revoke it immediately, audit install base for evidence of malicious updates, notify affected users

---

Step 5 — Incident Response for Extension Compromise

If a developer has an active GlassWorm extension:

1. Network isolation — disconnect workstation from corporate network before any investigation

2. Credential rotation — rotate ALL credentials accessible from that environment:

- Git provider (GitHub, GitLab, Bitbucket) SSH keys and personal access tokens

- Cloud provider credentials (AWS, GCP, Azure) — check CloudTrail/Audit logs for anomalous API calls in past 30 days

- AI API keys (OpenAI, Anthropic, etc.) — check for unusual usage spikes

- Database credentials if .env files were in any open workspace

3. Extension log review:

   # VS Code extension host logs
   ~/.config/Code/logs/*/exthost*/
   # Network connections from VS Code process (macOS)
   lsof -i -n -P | grep -E "(Code|cursor)" > network_at_time_of_discovery.txt

4. Examine workspace files for signs of data staging or exfiltration markers

5. Reimagine the endpoint — do not trust the workstation post-compromise; rebuild from known-good image

6. Threat hunt laterally — if the developer had production deployment access, audit all recent deployments for unauthorized changes

---

Step 6 — Monitoring Dashboard

Track the following metrics in your SIEM:

| Metric | Alert Threshold |

|---|---|

| New extension installs across fleet | > 5/day per team without change request |

| IDE process outbound connections to uncategorized hosts | Any occurrence |

| Developer credential rotation events | Triggered without expected rotation cycle |

| Extension directory changes outside business hours | Any occurrence |

| Failed cloud auth from developer IPs | > 3 in 1 hour |

---

Sources

1. Socket Security — "73 Open VSX Sleeper Extensions Linked to GlassWorm Activate New Malware Campaign" (April 2026): https://socket.dev/blog/glassworm-april-2026

2. The Hacker News — "Researchers Uncover 73 Fake VS Code Extensions Delivering GlassWorm" (April 2026): https://thehackernews.com/2026/04/researchers-uncover-73-fake-vs-code.html

3. Wiz Research — "Dismantling a Critical Supply Chain Risk in VSCode Extension Marketplaces" (October 2025): https://www.wiz.io/blog/supply-chain-risk-in-vscode-extension-marketplaces

4. CSO Online — "Open VSX Extensions Hijacked: GlassWorm Malware Spreads via Dependency Abuse" (March 2026): https://www.csoonline.com/article/4145579/

5. NVD — CVE-2026-26268 (Cursor Sandbox Escape via .git/config): https://nvd.nist.gov/vuln/detail/CVE-2026-26268

6. SentinelOne Vulnerability Database — CVE-2026-31854 (Cursor RCE): https://www.sentinelone.com/vulnerability-database/cve-2026-31854/

7. HowToHarden.com — "Cursor Hardening Guide" (April 2026): https://howtoharden.com/guides/cursor/

8. ArmorCode Blog — "The NPM Supply Chain Attack Playbook That Still Works in 2026" (April 2026): https://www.armorcode.com/blog/the-npm-supply-chain-attack-playbook-that-still-works-in-2026

---

Lyrie.ai Cyber Research Division — Senior Analyst Desk