GlassWorm v2: 73 Sleeper Extensions Target AI Developer Toolchains

Key Takeaways

Researchers at Socket disclosed on April 25, 2026 that the GlassWorm threat cluster has continued to seed the Open VSX Registry through April 2026, tracking 73 additional impersonation extensions tied to the same actor responsible for the March 2026 wave [1][2]. Six of the 73 have already been activated to deliver malware — outsidestormcommand.monochromator-theme, keyacrosslaud.auto-loop-for-antigravity, krundoven.ironplc-fast-hub, boulderzitunnel.vscode-buddies, cubedivervolt.html-code-validate, and winnerdomain17.version-lens-tool — while the remainder are classified as high-confidence sleepers awaiting weaponization through the normal update channel [1][2]. Combined with prior waves, researchers have now linked GlassWorm to more than 320 artifacts published since December 21, 2025 [2].

The campaign now targets AI-assisted developer tooling materially, with at least one confirmed-malicious extension impersonating Google Antigravity and the broader Open VSX channel reaching every major VS Code-derived AI IDE. Open VSX is the primary extension registry for VS Code-derived AI IDEs — including Cursor, Windsurf, Google Antigravity, AWS Kiro, VSCodium, and Positron — because Microsoft restricts its own marketplace to first-party Visual Studio Code [3][4]. The presence of auto-loop-for-antigravity in the confirmed-malicious set is a direct impersonation of Google’s agentic IDE released in late 2025, and the Hacker News reporting confirms the campaign explicitly targets users of Cursor and Windsurf in addition to mainline VS Code [2][5]. The threat actor is also continuing to abuse Open VSX’s lower-friction publishing path despite the Eclipse Foundation’s mandatory pre-publish security checks that began in March 2026 [6].

Three findings matter most for security teams. First, the sleeper model defeats reactive detection: 67 of the 73 extensions have shown no malicious behavior to date and would pass any point-in-time scan, but each represents a pre-positioned distribution channel that can be flipped by a single update push [1]. Second, the delivery techniques have diversified to evade the controls that caught earlier waves — Zig-compiled native .node binaries execute outside the JavaScript sandbox, while heavily obfuscated JavaScript pulls payload .vsix files from GitHub releases at runtime rather than embedding malware in the published artifact [1][7]. Third, the post-installation toolkit is consistent across activations and broad in capability: a remote access trojan with HVNC and SOCKS-proxy modules, a rogue Chromium extension that harvests credentials and session cookies, and credential exfiltration targeting GitHub, npm, Open VSX, and cryptocurrency wallets — with explicit geofencing that aborts execution on Russian-locale systems [1][8].

Background

From Worm to Sleeper Network

GlassWorm was first publicly documented in October 2025 by Koi Security as a self-propagating worm that hid JavaScript payloads inside Unicode variation-selector characters (U+FE00–U+FE0F and U+E0100–U+E01EF) so that malicious code rendered as blank space in editors and code review tools, with corroborating analysis from Truesec and Veracode shortly thereafter [9][10][15]. The campaign harvested GitHub, npm, and Open VSX credentials from compromised developers and used them to push poisoned updates to other extensions and packages those developers maintained, producing a self-replicating spread pattern. By March 2026, researchers had documented more than 150 GitHub repositories alongside npm and Open VSX components affected in a single concentrated wave [11].

The April 2026 wave that this note documents is structurally different. Rather than worming through compromised maintainer accounts, the operator is publishing fresh imposter extensions from new attacker-controlled namespaces — what Socket has named “sleeper extensions”: packages that are deliberately published before they are weaponized, accumulate trust through downloads and time, and only later receive a malicious update through the normal extension update channel [1][2]. This shift converts the campaign from an opportunistic credential-harvest into a pre-positioned distribution network, where the attacker controls a roster of dormant publishing channels that can be activated on demand.

Why Open VSX Concentrates the Attack Surface

The Open VSX Registry, maintained by the Eclipse Foundation, sits at the intersection of two trends that have expanded its blast radius. First, Microsoft’s Visual Studio Marketplace terms of use restrict the marketplace to first-party Visual Studio Code, which means every VS Code fork must source extensions from elsewhere. Second, the AI-assisted IDE category has expanded substantially over the past eighteen months, with Cursor, Windsurf, Google Antigravity (released late 2025), AWS Kiro, VSCodium, Positron, and Trae now consuming extensions from Open VSX rather than from Microsoft’s marketplace [3][4]. That makes a single malicious or compromised Open VSX extension a multi-IDE infection vector by default — a Cursor user and a Windsurf user pulling the same extension are both exposed to the same payload.

The Eclipse Foundation began rolling out mandatory pre-publish security checks in February 2026, with enforcement against impersonation, secret exposure, and known-malicious patterns starting in March 2026 [6]. The April 2026 GlassWorm wave demonstrates the limits of those controls: the actor’s typosquatted naming patterns (for example, Emotionkyoseparate.turkish-language-pack impersonating the legitimate MS-CEINTL.vscode-language-pack-tr), benign-on-publication behavior, and runtime-only payload retrieval from GitHub releases all sidestep the categories of checks the registry currently enforces [1][6]. A separate disclosure earlier in the year flagged that AI-IDE forks including Cursor, Windsurf, Antigravity, and Trae had recommended extensions whose names did not exist on Open VSX, opening a parallel typosquatting pathway that GlassWorm-class actors could claim opportunistically [12].

Security Analysis

Anatomy of the April 2026 Wave

Socket’s tracking covers 73 impersonation extensions across two delivery patterns, summarized in the table below.

Sources: Socket, April 25, 2026 [1]; The Hacker News, April 27, 2026 [2]; Aikido, April 8, 2026 [7].

The native-binary path is the most operationally consequential of the three patterns observed in this wave because it bypasses host-editor JavaScript sandboxing and propagates across multiple installed editors in a single execution. In the Zig-compiled dropper variant first documented earlier in April, the .node files are loaded as Node.js native addons — the same mechanism legitimate extensions use for performance-sensitive work — which gives the dropper full operating-system-level access [7]. The dropper then enumerates every VS Code-compatible IDE on the workstation and silently installs a second-stage extension into each one using each editor’s command-line tooling, so a developer who runs Cursor as their daily driver but has VS Code and VSCodium also installed finds all three compromised [7]. One plausible analyst hypothesis for the Zig choice is that behavioral EDR detection models have historically been tuned more heavily against C/C++ compiler fingerprints than against newer toolchains; this is analyst inference rather than confirmed attacker rationale.

GitHub releases serve as the staging infrastructure across both delivery patterns. Socket identified three repositories — SquadMagistrate10/wnxtgkih, francesca898/dqwffqw, and ColossusQuailPray/oiegjqde — hosting the second-stage .vsix payloads [1]. This represents a partial pivot away from earlier waves’ heavier reliance on the Solana blockchain as a command-and-control dead drop, though the Solana mechanism remains in the toolkit: researchers have observed Solana memo transactions used to update payload URLs as the attacker rotated infrastructure across late 2025 and early 2026 [8]. The hybrid posture — GitHub releases for active staging, Solana for resilient C2 fallback — is consistent with an actor optimizing for takedown resistance.

Confirmed Malicious Extensions and the AI-IDE Targeting Signal

Six extensions in the April 2026 cluster have been observed delivering malware to date, listed in the table below.

Source: The Hacker News, April 27, 2026 [2].

The auto-loop-for-antigravity entry is the clearest signal of intent toward the AI-IDE category. Google Antigravity, released in November 2025 as Google’s agentic development platform, sources its extensions from Open VSX [3][13]. An extension that purports to extend Antigravity’s automation capabilities is a credible lure for exactly the developer profile most likely to grant agent-class permissions — file system access, shell execution, network egress — to its tooling. Compromise at that layer gives the adversary access not only to the developer’s credentials but to the agentic AI’s operational context: the repositories the agent reads, the code the agent writes, the pull requests the agent opens, and in many configurations the shell commands the agent executes. This is a MAESTRO Layer 3 (execution environment) compromise that propagates silently into every artifact the developer produces after infection.

The ironplc-fast-hub entry deserves separate attention because it indicates targeting beyond mainstream developer environments into operational technology development workflows. IronPLC is an open-source PLC runtime; an extension impersonating tooling for that ecosystem narrows the victim profile to industrial control system engineers, whose workstations commonly sit at the IT/OT boundary. ICS-engineer workstations have featured in prior OT-targeting campaigns as a pre-positioning step for follow-on intrusion into operational environments, a pattern documented at length in industry ICS threat reporting and consistent with how this targeting signal should be interpreted.

Post-Compromise Toolkit

The post-installation behavior across the activated April 2026 extensions is consistent with the GlassWorm capability set documented through prior waves. Researchers describe the campaign goals as “run malware that avoids Russian systems, steal sensitive data, install a remote access trojan (RAT), and stealthily deploy a rogue Chromium-based extension to siphon credentials” [2]. The geofencing aborts execution on Russian-locale systems — a behavior most often associated with actors operating in or aligned with Russian-speaking criminal ecosystems, though attribution should be treated cautiously absent independent corroboration. The RAT supports a Hidden VNC module for remote desktop access, a WebRTC-based SOCKS proxy for traffic relay, and browser data theft modules that target GitHub, npm, Open VSX, Git credential stores, and cryptocurrency wallet extensions [8]. The rogue Chromium extension component installs a malicious browser extension that masquerades as an offline version of Google Docs, logs keystrokes, captures session cookies, and exfiltrates active session tokens [8].

For organizations operating AI-assisted development at scale, the credential-theft surface deserves particular attention. AI IDEs commonly store API credentials for cloud model providers (Anthropic, OpenAI, Google, internal model gateways) in user-scope configuration files or OS keychains, and many maintain persistent OAuth tokens for GitHub or GitLab to enable agent-driven commit and PR workflows. Specific storage mechanisms vary by product, with some moving toward short-lived tokens or hardware-backed credential stores. Even with that variation, a single compromised workstation can therefore expose not only source code but the AI-API budgets of the developer’s organization and the repository write permissions the developer’s tooling has accumulated.

Why the Sleeper Pattern Defeats Reactive Defense

The sleeper-extension model substantially erodes the dominant defensive posture in the extension ecosystem, which is reactive scanning and post-publication takedown. A sleeper extension is benign on the day it is published, benign on the day it is scanned, and benign through whatever monitoring window the registry enforces — until the moment its maintainer pushes an update with malicious behavior. By then, the extension’s installation base has already absorbed the update through the standard auto-update path, and the takedown that follows recovers an installation count that remains compromised on every workstation that received the update before the registry pulled the package. Socket’s observation that 67 of 73 tracked extensions remain in sleeper status, with only six confirmed activations, indicates that the attacker has built substantially more pre-positioned distribution capacity than has been used to date [1]. Defenders should plan for the possibility of a coordinated mass-activation event using the remaining sleeper inventory.

Recommendations

Immediate Actions

Security teams that support developers using Open VSX-sourced IDEs should treat the April 2026 wave as an active threat and inventory which extensions are installed on which workstations within the next several days. Most enterprise EDR products do not enumerate VS Code-class IDE extensions by default; discovery typically requires reading user-scope .vscode/extensions/, .cursor/extensions/, .windsurf/extensions/, and equivalent directories. Cross-reference installed extensions against the six confirmed-malicious identifiers listed in the table above and remove any matches. For the broader 73-extension cluster, Socket maintains a public indicator list that should be ingested into endpoint hunting tooling [1].

Workstations that have run any of the six confirmed-malicious extensions should be treated as compromised pending forensic review. The native-dropper variant installs a secondary .vsix (such as autoimport-2.7.9.vsix) impersonating legitimate extensions, so the full extension list on each editor on the workstation must be reviewed, not only the editor through which the original infection arrived [7]. Developer credentials for GitHub, npm, Open VSX, internal package registries, and any AI-API keys that have been resident on the workstation should be rotated; the post-compromise toolkit explicitly targets these credential stores [8].

Short-Term Mitigations

Over the next several weeks, organizations should establish enterprise governance over IDE extensions equivalent to what they apply to browser extensions. Pin allowlisted extensions through MDM-deployed configuration, disable arbitrary extension installation where the developer’s workflow does not require it, and, where business needs permit, route extension acquisition through an internal mirror that proxies Open VSX with additional scanning and an organization-controlled approval queue. AI-IDE forks (Cursor, Windsurf, Antigravity, Kiro) should be enrolled in the same allowlist regime as VS Code rather than treated as a separate category, because they share the extension installation path and the same attack surface.

Network controls should constrain where IDEs can pull executable content. The April 2026 delivery pattern stages payloads on GitHub releases under attacker-controlled repositories, which means egress monitoring that flags IDE processes downloading .vsix files from non-allowlisted GitHub repositories will catch the active infection step. The same controls should block unexpected outbound connections to the Solana blockchain RPC endpoints that GlassWorm has used as a fallback C2 channel [8].

Coding agents and CLI agents warrant separate hardening because the impact gradient is steepest there. AI-assisted IDEs that grant agents shell access, file write, or repository commit permissions should be configured to require human approval before any agent action that touches .vsix files, extension manifests, or the local extension directories of any installed editor. Where vendors support it, scope agent file-system access to project directories only, excluding user-level extension paths.

Strategic Considerations

The April 2026 wave makes clear that the extension layer is now a primary attack surface for the AI-developer category, and the implicit security model under which developers selected extensions on social-trust signals alone (download count, publisher name, GitHub stars) is no longer adequate against the sleeper pattern. Organizations should expect to invest meaningfully in extension governance over the next twelve to eighteen months, on a maturity trajectory comparable to the build-out of container-image governance over the prior five years: signed publishers, internal registries, behavioral telemetry on what extensions do at runtime, and procurement-level review of any extension that gains agent-class privileges.

Procurement and vendor-management practices need to extend to AI-IDE vendors specifically. Standard vendor security questionnaires should now ask whether the vendor scans extensions before serving them to its IDE users, whether it maintains its own allowlist or relies entirely on Open VSX’s pre-publish controls, what its takedown SLA is when a malicious extension is reported, and whether it supports enterprise allowlisting features. The pre-publish controls Eclipse Foundation introduced in March 2026 are necessary but, on the evidence of the April wave, not sufficient — defense in depth at the consumer-IDE layer remains required.

Finally, the AI-IDE forks should be brought into the scope of the organization’s secure-development standards. A Cursor-using engineering team that has its developer credentials and AI-API keys exfiltrated has effectively had a backdoor planted into every repository it commits to thereafter, including any model-training data, prompt configurations, or agentic-workflow definitions stored alongside source. Treating AI-IDE workstations as Tier-0 assets — at least until the extension governance regime above is in place — is consistent with the actual blast radius of compromise.

CSA Resource Alignment

The findings in this note connect directly to several existing CSA AI Safety Initiative resources. The MAESTRO Agentic AI Threat Modeling framework provides the layered model that maps GlassWorm-class extension compromise as a Layer 3 (execution environment) attack that propagates into Layer 4 (deployment/serving) when the compromised developer ships poisoned code, prompts, or agent configurations into production. The framework should be the default reference when security architects reason about the blast radius of developer-workstation compromise on agentic systems [14].

The AI Controls Matrix (AICM) — CSA’s superset of the Cloud Controls Matrix that incorporates AI-specific control objectives — addresses the supply chain integrity, application development security, and identity-and-access controls that map cleanly to the extension-governance recommendations made in this note. Application-provider auditing guidance under AICM addresses the third-party component review and software bill of materials concerns that underlie effective extension governance.

CSA’s Securing Autonomous AI Agents guidance and prior research on the OpenClaw desktop-agent class establish the human-in-the-loop and capability-gating patterns that materially reduce post-compromise impact when an AI-IDE workstation is breached. STAR for AI provides an assessment framework through which organizations can evidence that the relevant developer-environment and agent-permission controls are present and operating. The CSA research notes on the prior GlassWorm waves — covering the original Unicode-variation-selector technique, the March 2026 transitive dependency abuse, and the April 2026 Zig-dropper variant — provide the longitudinal context against which the April 2026 sleeper wave should be read.

References

[1] Socket Research Team. “73 Open VSX Sleeper Extensions Linked to GlassWorm Show New Malware Activations.” Socket, April 25, 2026.

[2] The Hacker News. “Researchers Uncover 73 Fake VS Code Extensions Delivering GlassWorm v2 Malware.” The Hacker News, April 27, 2026.

[3] Bridgwater, Adrian. “Eclipse Foundation Offers Enterprise-Grade Open Source Alternative to Microsoft’s VS Code Marketplace.” The New Stack, April 21, 2026.

[4] The Register. “AWS Backs Open VSX as Rust Survey Shows VS Code Decline.” The Register, March 3, 2026.

[5] Cybersecurity News. “73 Open VSX Sleeper Extensions Linked to GlassWorm Activate New Malware Campaign.” Cybersecurity News, April 26, 2026.

[6] The Hacker News. “Eclipse Foundation Mandates Pre-Publish Security Checks for Open VSX Extensions.” The Hacker News, February 2026.

[7] Aikido Security. “GlassWorm Goes Native: New Zig Dropper Infects Every IDE on Your Machine.” Aikido, April 8, 2026.

[8] The Hacker News. “GlassWorm Malware Uses Solana Dead Drops to Deliver RAT and Steal Browser, Crypto Data.” The Hacker News, March 2026.

[9] Truesec. “GlassWorm: Self-Propagating VSCode Extension Worm.” Truesec, October 2025.

[10] Veracode. “GlassWorm: The First Self-Propagating VS Code Extension Worm.” Veracode, October 2025.

[11] Aikido Security. “GlassWorm Returns: Invisible Unicode Malware Found in 150+ GitHub Repositories.” Aikido, March 2026.

[12] The Hacker News. “VS Code Forks Recommend Missing Extensions, Creating Supply Chain Risk in Open VSX.” The Hacker News, January 2026.

[13] Google Developers Blog. “Build with Google Antigravity, Our New Agentic Development Platform.” Google, November 20, 2025.

[14] Cloud Security Alliance. “Agentic AI Threat Modeling Framework: MAESTRO.” Cloud Security Alliance AI Safety Initiative, February 6, 2025.

[15] Koi Security. “Live Updates: GlassWorm — First Self-Propagating Worm Using Invisible Code Hits Open VSX and VS Code Marketplaces.” Koi Security, October 2025.