Published: April 28, 2026

Author: Lyrie Research (research.lyrie.ai)

Stream: AI Threats

Status: Actively exploited — no vendor patch available

IOC SHA256 (native binary): 1b62b7c2ed7cc296ce821f977ef7b22bae59ef1dcdb9a34ae19467ee39bcf168

IOC SHA256 (VSIX payload): 97c275e3406ad6576529f41604ad138c5bdc4297d195bf61b049e14f6b30adfd

---

TL;DR

Socket Research identified 73 malicious extensions on Open VSX — the Eclipse-backed alternative to the Microsoft Marketplace — as part of an active GlassWorm campaign first disclosed on April 25, 2026. Six are already weaponized and pulling second-stage payloads from github.com/SquadMagistrate10/wnxtgkih; the remaining 67 are dormant, pre-positioned on developer machines, and can activate at any time without a new install. The VSIX format means every IDE that accepts VSIX packages is exposed: Microsoft VS Code, Anysphere Cursor, Codeium Windsurf, OpenVSCode-Server. No CVE is assigned — this is a campaign-class attack, and there is no vendor patch. Mitigation is manual.

---

What is GlassWorm and why this campaign is different

GlassWorm is a persistent threat actor group known for targeting developer toolchains through software supply-chain manipulation. Prior campaigns — documented as far back as 2024 — focused on PyPI typosquats and npm package poisoning targeting specific framework communities. The April 2026 wave is different in three ways.

First, the distribution channel. Open VSX Registry, maintained by the Eclipse Foundation, hosts extensions compatible with any VS Code-derived IDE. It was created specifically to serve IDEs that cannot or will not use Microsoft's proprietary Marketplace — Cursor, Windsurf, Gitpod, OpenVSCode-Server, VSCodium, all rely on it. Open VSX operates with a significantly lighter review process than the official Microsoft Marketplace. GlassWorm chose it not despite its smaller footprint, but because of it: lower review friction, high-trust reputation (Eclipse Foundation branding), and guaranteed compatibility with every VSIX-consuming IDE in the ecosystem.

Second, the sleeper model. Previous GlassWorm campaigns activated immediately on install. The April 2026 wave pre-positioned 73 extensions across Open VSX, then activated only a subset — 6 of the 73 — while leaving 67 dormant. The dormant extensions are already installed on developer machines. They require no new user action to become dangerous. GlassWorm controls the activation switch via the second-stage payload server (github.com/SquadMagistrate10/wnxtgkih); when they flip it, the dormant 67 become active simultaneously.

Third, the target profile. The 73 extensions are styled as legitimate developer utilities: color themes, code formatting helpers, language pack extensions. Developers who install utility extensions do not expect them to touch their CI/CD pipelines, cloud credentials, or source code. That expectation is the attack.

Socket Research's primary disclosure (socket.dev/blog/73-open-vsx-sleeper-extensions-glassworm, April 25) remains the authoritative source for the full extension list and IOC data. CybersecurityNews provided independent technical breakdown confirming the IOCs and dual-delivery model (cybersecuritynews.com/73-open-vsx-sleeper-extensions-linked-to-glassworm-malware/, April 26). BleepingComputer confirmed editorial tracking of continued exploitation activity (bleepingcomputer.com/news/security/glassworm-malware-attacks-return-via-73-openvsx-sleeper-extensions/, April 27–28).

---

The attack chain

Step by step, how a GlassWorm extension compromises a developer machine:

Step 1 — Install. A developer discovers one of the 73 extensions on Open VSX — presented as a legitimate utility, rated, with a credible publisher name. They install via the IDE's extension panel. The VSIX package downloads to the local extension store (~/.vscode/extensions/ or equivalent for Cursor/Windsurf).

Step 2 — IDE startup activation. The extension's package.json manifest declares "activationEvents": ["*"] — activating on every IDE startup, not only when a specific file type is opened. Every time the developer opens their IDE, the extension's activate() function executes.

Step 3 — C2 beacon. On activation, the extension makes an outbound HTTP request to github.com/SquadMagistrate10/wnxtgkih — a GitHub repository serving as a command-and-control payload store. If the extension is in the active set (currently 6 of 73), the server responds with a second-stage VSIX payload.

Step 4 — Second-stage drop. The VSIX payload (97c275e3406ad6576529f41604ad138c5bdc4297d195bf61b049e14f6b30adfd) is written to disk and unpacked. It deploys a native binary (1b62b7c2ed7cc296ce821f977ef7b22bae59ef1dcdb9a34ae19467ee39bcf168) which the extension spawns as a child process.

Step 5 — Exfiltration. The native binary targets: environment variables (AWS_ACCESS_KEY_ID, GITHUB_TOKEN, OPENAI_API_KEY, and equivalents), local SSH keys, .env files in any open workspace, git credential stores, CI/CD configuration files. Collected data is transmitted to attacker infrastructure. The attacker's goal — per Socket Research — is to steal CI/CD tokens and cloud credentials, pivot through developer machines into corporate networks, and exfiltrate source code.

A representative malicious package.json manifest fragment (synthesized from Socket's disclosure pattern — not an exact quote from any specific extension, but representative of the class):

{
  "name": "monochromator-theme",
  "displayName": "Monochromator Theme",
  "description": "Clean monochrome color theme for VS Code",
  "version": "1.0.3",
  "publisher": "outsidestormcommand",
  "engines": { "vscode": "^1.75.0" },
  "categories": ["Themes"],
  "activationEvents": ["*"],
  "main": "./out/extension.js",
  "contributes": {
    "themes": [{
      "label": "Monochromator",
      "uiTheme": "vs-dark",
      "path": "./themes/monochromator-color-theme.json"
    }]
  },
  "scripts": { "postinstall": "node ./out/postinstall.js" }
}

Two red flags in the manifest: "activationEvents": [""] (a color theme has no need to activate on every startup — legitimate themes use "" only when providing language support) and postinstall script (no theme needs post-install execution). Neither flag triggers an Open VSX review hold.

---

Why VSIX is the perfect attack surface

The VSIX format is a renamed ZIP archive. Open the file with any ZIP utility and you get a folder containing package.json, bundled JavaScript, and optionally pre-compiled native binaries. There is no code-signing requirement on Open VSX. There is no sandboxed execution model — extensions run in the IDE's Node.js process with full access to child_process, fs, and net. The extension host process shares the same user context as the IDE itself.

Activation events compound this. The "activationEvents": ["*"] pattern tells the IDE to load the extension immediately on startup, before the user opens any file. A developer who installed one of the 73 extensions last week is running attacker code every single time they open VS Code — and has no UI indication that anything is happening.

The cross-IDE vector is a direct consequence of the format. Microsoft (VS Code), Anysphere (Cursor), Codeium (Windsurf), Eclipse Foundation (OpenVSCode-Server), and every other VSIX-consuming IDE all execute the same package.json manifest and the same activate() function. One malicious package, every IDE. This is not a VS Code vulnerability; it is a consequence of the entire ecosystem converging on a single extension format with no per-IDE code signing or behavior sandboxing.

Microsoft's official Marketplace runs an automated malware scanning pipeline and manual review sampling before publication. Open VSX does not run an equivalent pipeline at the same scale. That asymmetry made Open VSX the chosen distribution channel for this campaign.

---

The 73 — and the 67 dormant ones

This is the detail that makes the April 2026 GlassWorm wave structurally different from a typical malware distribution campaign: the majority of the attack surface is already deployed and waiting.

Of the 73 identified extensions:

• 6 are actively firing — making C2 connections, pulling the second-stage payload, and running the native binary on affected machines right now.
• 67 are dormant — installed on developer machines, activating on IDE startup, beaconing to github.com/SquadMagistrate10/wnxtgkih, but currently receiving a benign (or null) response from the C2 server.

GlassWorm can flip those 67 from dormant to active at any moment by updating the payload server. No new installs required. No social engineering required. No user action required. The infrastructure is already in place.

Named extensions confirmed in Socket's disclosure include outsidestormcommand.monochromator-theme and boulderzitunnel.vscode-buddies. Socket Research maintains the full list of all 73 identifiers with publisher names and extension IDs at socket.dev/blog/73-open-vsx-sleeper-extensions-glassworm. Defenders should pull the canonical list directly from that disclosure — any partial list in a secondary source risks being incomplete.

The dormant 67 are not "safe to leave installed." They are an attack that has not yet been activated.

---

What defenders should do tomorrow morning

No patch is available. No IDE vendor has shipped a blocking update. Mitigation is manual and needs to happen before GlassWorm activates the remaining 67.

a) Inventory installed extensions across your dev fleet.

Run this on every developer machine. For VS Code:

# VS Code
code --list-extensions

# Cursor
cursor --list-extensions

# Windsurf (if CLI available)
windsurf --list-extensions

# OpenVSCode-Server — list from the server's extension directory
ls ~/.vscode-server/extensions/

Cross-reference the output against Socket's full list of 73 extension IDs. Any match = remove immediately: code --uninstall-extension <publisher.extension-name>.

For fleet-scale inventory, dump the extension lists from all developer machines into a central store and run a diff against the Socket IOC list. A one-liner to export from a single machine:

code --list-extensions | sort > extensions-$(hostname)-$(date +%Y%m%d).txt

b) Hash-block the two known SHA256s in EDR.

Add both hashes to your EDR's block list tonight:

# Example: CrowdStrike Custom IOC (hash type: SHA256, action: prevent)
SHA256: 1b62b7c2ed7cc296ce821f977ef7b22bae59ef1dcdb9a34ae19467ee39bcf168
Description: GlassWorm native binary — Open VSX campaign April 2026

SHA256: 97c275e3406ad6576529f41604ad138c5bdc4297d195bf61b049e14f6b30adfd
Description: GlassWorm VSIX second-stage payload — Open VSX campaign April 2026

Adapt the syntax for your EDR platform (SentinelOne, Defender for Endpoint, Carbon Black). The principle is the same: prevent execution before the process starts, not after.

c) Audit Open VSX vs. Microsoft Marketplace as the extension source.

Check where each installed extension originates. Extensions installed from the official Microsoft Marketplace (marketplace.visualstudio.com) went through Microsoft's review pipeline. Extensions from Open VSX (open-vsx.org) did not receive equivalent scrutiny. For extensions sourced from Open VSX, apply the strictest manual review: check publisher history, cross-reference against Socket's IOC list, and confirm the extension has a legitimate and verifiable public presence outside the registry.

d) Block github.com/SquadMagistrate10 at the network perimeter.

Add a network egress rule blocking outbound connections to github.com/SquadMagistrate10/wnxtgkih (the active C2 payload repository). This disrupts the second-stage delivery for currently active extensions and prevents dormant extensions from receiving activation payloads:

# Example: Palo Alto Networks URL filtering custom block
URL: github.com/SquadMagistrate10/*
Category: Malware C2
Action: Block + Alert

Blocking at the network layer does not remove the extensions or the already-dropped native binary — but it cuts the kill chain at payload delivery.

---

The Lyrie Shield approach

Shield's policy engine intercepts child-process spawns from the IDE extension host. When a VSIX extension calls child_process.spawn() or child_process.exec() with an unknown binary — one that is not in Shield's allow-list for that extension publisher — Shield blocks the spawn and raises a process violation alert. The GlassWorm native binary (1b62b7c2ed7cc296ce821f977ef7b22bae59ef1dcdb9a34ae19467ee39bcf168) would be caught at this stage: it is an unsigned, unlisted process spawn originating from the extension host.

Shield's Stages A–F validator can also flag the outbound HTTP beacon in Stage D: the C2 request to github.com/SquadMagistrate10/wnxtgkih pattern-matches against the exfiltration URL profile and triggers a quarantine before the payload arrives.

The open-source lyrie-agent SDK exposes a scanner API that accepts a list of SHA256 hashes and returns a match against our known-malicious hash registry. Running a post-install check against the two GlassWorm IOCs takes three lines:

from lyrie_agent import Shield

shield = Shield()
result = shield.scan_hashes([
    "1b62b7c2ed7cc296ce821f977ef7b22bae59ef1dcdb9a34ae19467ee39bcf168",
    "97c275e3406ad6576529f41604ad138c5bdc4297d195bf61b049e14f6b30adfd"
])
print(result)  # returns match details and threat classification

Install: pip install lyrie-agent

What Lyrie does not yet cover, stated plainly: we do not currently auto-block extensions by Open VSX publisher identity. Shield knows about the GlassWorm binary hashes and process spawn patterns, but it does not yet maintain a real-time feed of flagged Open VSX publisher IDs that would block installation before the extension runs at all. That capability — pre-install publisher reputation scoring for VSIX packages — is on the roadmap. It is not in the current release.

We also do not currently provide fleet-wide extension inventory collection. The code --list-extensions audit step above is manual. Automated fleet inventory scanning is a Shield Enterprise feature on the roadmap.

---

The bigger picture — IDE supply chain is the new dependency supply chain

The 2021–2022 npm and PyPI supply-chain wave taught defenders to treat open-source packages as untrusted inputs. The 2024–2025 model-supply-chain wave extended that lesson to HuggingFace model weights. The April 2026 GlassWorm campaign is the same attack class, shifted to IDE extensions.

The stakes are higher here because of who runs these tools and what they run alongside them. VS Code, Cursor, Windsurf, Continue, Cline, Aider — these are not passive document viewers. They are agent-grade tools with filesystem read/write, terminal execution, language-server hooks, Git integration, and in Cursor and Windsurf's case, direct LLM API access with the developer's credentials loaded in the session. A compromised VSIX extension runs in the same process as the agent that has access to ~/.env, ~/.aws/credentials, and every open workspace.

This connects directly to taxonomy class #4 from our agent-threats field guide: supply-chain attacks on agent frameworks. The prior examples were Python packages. This is the same attack class but delivered through a format that every agentic coding tool in the ecosystem accepts. An attack on VSIX is an attack on every developer who has adopted AI-assisted coding — which in 2026 is most of them.

The pattern that makes this a long-term structural risk: Open VSX exists because the agentic IDE ecosystem deliberately forked away from Microsoft's closed Marketplace. Cursor, Windsurf, VSCodium — they chose Open VSX because it has no usage tracking, no telemetry, no Microsoft dependency. That was a reasonable architectural choice. The cost is reduced review coverage. GlassWorm is exploiting exactly that trade-off.

---

Reproducible artifacts

• Socket Research primary disclosure (Apr 25): socket.dev/blog/73-open-vsx-sleeper-extensions-glassworm
• CybersecurityNews technical breakdown (Apr 26): cybersecuritynews.com/73-open-vsx-sleeper-extensions-linked-to-glassworm-malware/
• BleepingComputer confirmation (Apr 27–28): bleepingcomputer.com/news/security/glassworm-malware-attacks-return-via-73-openvsx-sleeper-extensions/
• IOC — native binary SHA256: 1b62b7c2ed7cc296ce821f977ef7b22bae59ef1dcdb9a34ae19467ee39bcf168
• IOC — VSIX payload SHA256: 97c275e3406ad6576529f41604ad138c5bdc4297d195bf61b049e14f6b30adfd
• C2 domain to block: github.com/SquadMagistrate10/wnxtgkih
• Agent-threats taxonomy: research.lyrie.ai/streams/agent-threats
• lyrie-agent SDK: github.com/overthetopseo/lyrie-agent
• Python install: pip install lyrie-agent

---

Lyrie Verdict

GlassWorm's April 2026 campaign is the canonical example of a sleeper supply-chain attack targeting agentic developer tools: pre-position at scale, activate selectively, maintain dormant infrastructure for a mass activation event. The 67 dormant extensions are not a future threat — they are a present threat waiting for a command. Hash-block both IOCs in your EDR tonight. Run code --list-extensions across your dev fleet and cross-reference against Socket's full list of 73 before your developers open their IDEs tomorrow morning. Block github.com/SquadMagistrate10 at the network perimeter now, not after you've finished investigating. Every IDE extension is a binary running with your user's privileges and access to every file in every workspace you have open. Treat it that way.

---

Lyrie Research is the offensive security research arm of Lyrie.ai and OTT UAE. We publish agent threat research, detection content, and open-source tooling at research.lyrie.ai.

Contact: [email protected] | Repo: github.com/overthetopseo/lyrie-agent