GlassWorm: Open VSX Transitive Dependency Supply-Chain Escalation

Key Takeaways

The GlassWorm campaign, active since at least October 2025, has executed a significant escalation in its developer-targeting supply chain operations. Socket Research Team identified at least 72 additional malicious Open VSX extensions between January 31 and March 13, 2026, built around a novel technique that abuses the extensionPack and extensionDependencies manifest fields to transform initially benign extensions into transitive delivery vehicles for malicious loaders [1]. This mechanism allows an extension that passes marketplace review to later silently pull in a payload-bearing dependency without any update to the extension itself, effectively bypassing conventional code review at the point of initial publication.

The campaign spans multiple attack surfaces—Open VSX, npm, and GitHub—with associated indicators including 88 malicious npm packages (attributed to a variant called PhantomRaven, active from November 2025 through February 2026) and an estimated 151 GitHub repositories compromised between March 3 and March 9, 2026, via invisible-Unicode payload injection [1][2]. Earlier in the campaign, on January 30, 2026, the threat actor compromised a legitimate developer’s Open VSX publishing credentials and silently poisoned four established extensions with a combined 22,000+ prior downloads [3].

The GlassWorm loader is a staged, heavily obfuscated macOS infostealer that uses Solana blockchain transaction memos as a dead-drop command-and-control resolver to rotate infrastructure without republishing. Its theft targets span browser credentials, cryptocurrency wallets, cloud provider tokens, SSH keys, and CI/CD pipeline secrets [3].

Security teams should treat the Open VSX ecosystem—and any editor extension marketplace—as an active supply chain risk vector requiring the same dependency governance controls applied to package managers such as npm and PyPI.

Background

The Open VSX Registry and Its Security Model

Open VSX is a widely adopted alternative to the proprietary Visual Studio Marketplace, providing extension distribution for VS Code-compatible editors such as VSCodium, Eclipse Theia, Gitpod, and others that cannot or do not access Microsoft’s marketplace. The registry operates as a community-governed platform under the Eclipse Foundation, with publication access gated on developer accounts rather than centralized binary signing or mandatory code review.

This trust model—relying principally on publisher reputation and post-hoc community reporting—creates a structurally permissive environment. Open VSX has not publicly documented automated pre-publication security scanning comparable to npm’s or PyPI’s published tooling; while those registries have implemented automated secret-scanning and increasingly sophisticated malware detection pipelines, Open VSX’s equivalent controls remain limited as of this writing. The GlassWorm campaign has systematically exploited this gap across a campaign spanning more than five months [1][3].

Campaign History and Evolution

Socket and Koi Security initially flagged GlassWorm activity in October 2025, when the first malicious Open VSX extensions appeared using direct payload embedding. From December 2025 through January 2026, researchers identified a cluster of 13 additional malicious extensions using typosquatting to impersonate legitimate developer tools [3]. These early-campaign extensions planted the loader directly in the published package, requiring the threat actor to create new publisher accounts for each campaign wave.

The January 30, 2026 account compromise incident represented a notable tactical shift. Rather than creating fresh publisher identities, the threat actor obtained or inferred the access token for the established developer account oorzc and pushed malicious updates to four extensions with an existing download base: FTP/SFTP/SSH Sync Tool (v0.5.1, approximately 17,000 downloads), I18n Tools (v1.6.8, approximately 3,600 downloads), vscode mindmap (v1.0.61, approximately 3,200 downloads), and scss to css (v1.3.4, approximately 1,300 downloads) [3]. The Open VSX security team assessed the incident as “consistent with leaked tokens or other unauthorized access” [3]. Malicious releases remained available until February 2, 2026.

The March 2026 wave—72 extensions using transitive dependency abuse—represents a third-generation evolution in technique that, whether by design or adaptation, circumvents the defenses most applicable to the earlier account-compromise and typosquatting phases.

Security Analysis

The Transitive Dependency Escalation Technique

The core innovation documented by Socket in its March 13, 2026 report is the systematic abuse of two VS Code extension manifest fields: extensionPack and extensionDependencies [1][2]. Both fields cause the editor to automatically install additional extensions alongside the declaring package. In legitimate usage, extensionPack bundles a curated set of related tools, while extensionDependencies specifies extensions a package requires to function correctly. Neither field appears to trigger equivalent scrutiny to the package’s own source code at the time of initial review, based on the technique’s observed success across 72 published extensions.

The GlassWorm technique proceeds in two phases. In the first phase, the threat actor publishes an extension that appears functionally plausible—a linter, formatter, code runner, or AI coding assistant companion—without embedding any malicious code. This extension may pass cursory review because its source is benign. In the second phase, the actor releases an update that adds an extensionPack or extensionDependencies entry pointing to a separately published extension containing the GlassWorm loader. The editor installs the loader extension automatically in the background, with no notification to the developer other than the appearance of an additional installed package. As Socket described the technique: “An extension that looked non-transitive and comparatively benign at initial publication can later become” a malicious delivery vehicle [1].

Viewed analytically, this approach separates the act of gaining trust—the initial benign publication—from the act of delivering the payload, which arrives via a dependency relationship added after trust has been established. It also enables the loader to be updated independently of the declaring extension, allowing the threat actor to rotate payloads without triggering a new review of the extensions that install it.

Loader Technical Analysis

The GlassWorm loader employs a multi-stage execution chain with significant obfuscation. In Stage 0, the extension activates an AES-256-CBC encrypted payload embedded as a long hexadecimal string; the hardcoded decryption key is wDO6YyTm6DL0T0zJ0SXhUql5Mo0pdlSz and the initialization vector is c4b9a3773e9dced6015a670855fd32b [3]. The decrypted content is immediately executed via JavaScript’s eval(), significantly reducing the utility of static analysis on the distributed package, since the payload is never present in plaintext form in the published extension files.

Stage 1 introduces two notable evasion capabilities. First, the loader performs geofencing: it checks the system locale, language settings, and UTC timezone offset (UTC+2 through UTC+12) and aborts execution on systems consistent with Russian locales—a pattern documented across multiple malware families attributed to Russia-linked actors, consistent with a common operational security practice of excluding systems in the operator’s home jurisdiction [3]. Second, rather than hardcoding a command-and-control server address, the loader queries the Solana blockchain, reading the transaction memo associated with the address BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC to retrieve the current C2 endpoint [3]. This “EtherHiding” technique—adapting a method first publicly documented in cryptocurrency-focused phishing campaigns and subsequently adopted by nation-state actors—means the C2 infrastructure can rotate freely without republishing any extension code [3][8].

Stage 2 delivers a Node.js infostealer payload targeting macOS systems exclusively. Exfiltration destinations observed in the January 2026 incident included the IP address 45[.]32[.]150[.]251 [3]. The stealer’s collection scope is broad: browser credential databases and cookies from Firefox and Chromium-based browsers, cryptocurrency wallet application data (MetaMask, Electrum, Exodus, Atomic, Ledger Live, Trezor Suite, Binance, and TonKeeper), the macOS login keychain database (login.keychain-db), AWS credential files (~/.aws), SSH keys and known-hosts files (~/.ssh), Apple Notes databases, Safari cookies, FortiClient VPN configuration, npm tokens, and GitHub authentication artifacts [3]. The payload also establishes persistence by writing a LaunchAgent property list to ~/Library/LaunchAgents (e.g., com.user.nodestart.plist) to survive system reboots [3].

A fourth evasion capability identified in the March 2026 wave is the use of “Remote Dynamic Dependencies” (RDD): by fetching payload code from external URLs declared in package.json, the threat actor retains the ability to modify what the loader retrieves and executes in real time, without publishing any new version of any extension. This renders version pinning alone insufficient as a mitigation [1].

Obfuscation and AI-Assisted Evasion

Several attributes of the GlassWorm campaign indicate deliberate use of AI tooling on the offensive side. Aikido security researcher Ilyas Makari noted: “The malicious injections don’t arrive in obviously suspicious commits…This level of project-specific tailoring strongly suggests the attackers are using large language models” [2]. Commits exhibiting this project-specific tailoring—including plausible documentation updates, minor bug fix descriptions, and realistic changelog entries—significantly raise the bar for human review of commit history as a detection strategy, whether or not LLM involvement is ultimately confirmed. Invisible Unicode characters are used to encode payload content in commits that appear empty or benign when rendered in standard code editors and terminals [2].

This convergence of apparently AI-assisted social engineering at the commit level with blockchain-based C2 at the infrastructure level represents a measurable increase in operational complexity compared to earlier campaign phases.

Scope and Target Profile

The 72 malicious extensions identified in the March wave targeted extensions mimicking widely used developer utilities: linters, formatters, code runners, SQL tooling, PDF utilities, and—notably—companion extensions for AI-powered coding assistants including tools impersonating Claude Code and Google Antigravity [1][2]. The deliberate inclusion of AI assistant companions as camouflage reflects an understanding that developers currently deploying AI coding tools represent a high-value target profile: developers working with AI coding assistants commonly operate with elevated access to cloud credentials and pipeline tokens, and may install AI-recommended extensions with less friction than traditional vetting would require—making them a particularly attractive target.

Sample malicious extension IDs from the March 2026 wave include angular-studio.ng-angular-extension, crotoapp.vscode-xml-extension, gvotcha.claude-code-extension, mswincx.antigravity-cockpit, tamokill12.foundry-pdf-extension, turbobase.sql-turbo-tool, and vce-brendan-studio-eich.js-debuger-vscode [1]. These identifiers follow plausible naming conventions designed to pass casual inspection.

Recommendations

Immediate Actions

Organizations whose developers use VS Code-compatible editors with access to the Open VSX registry should treat the following as urgent priorities. Any developer who installed extensions from Open VSX between January 31 and March 14, 2026, should audit installed extensions against the known malicious IDs published by Socket [1] and remove any matches immediately. On macOS systems, ~/Library/LaunchAgents should be inspected for unexpected plist files with service names suggesting generic system or Node.js processes.

Credential rotation should be treated as mandatory for any developer whose environment may have been exposed. GitHub tokens warrant particular urgency given their potential for direct write access to source repositories and CI/CD pipelines, though AWS credentials and SSH keys may represent equivalent or higher risk depending on organizational architecture. npm access tokens and SSH keys should follow. Developers should also audit recent GitHub Actions workflow runs and CI/CD pipeline execution logs for anomalous activity consistent with credential use from unexpected IP addresses.

Short-Term Mitigations

Extension governance should be formalized. Organizations should establish an approved list of Open VSX extensions, reviewed against a known-good baseline, and enforce that list through policy or tooling. Where possible, extension installation should be restricted so that developers cannot install arbitrary marketplace packages in production development environments without team review. Socket’s GitHub application, CLI, and browser extension provide real-time analysis of extension dependencies and can detect extensionPack and extensionDependencies relationships that introduce new, unreviewed packages [3].

Version pinning—locking extensions to specific, reviewed versions—is a partial mitigation but is insufficient alone given GlassWorm’s use of Remote Dynamic Dependencies, which allow payload content to change without a version increment [1]. Pinning should be combined with network-level monitoring: developer workstations should have egress filtering or at minimum logging for unusual outbound connections, and Solana RPC endpoint access from development hosts should be considered anomalous absent an explicit business need.

For CI/CD environments, secrets should be scoped to the minimum necessary permissions and should ideally be injected at runtime rather than persisted on developer machines. Pipeline tokens should have short expiration windows and be rotated on a schedule independent of any incident response cycle.

Strategic Considerations

The GlassWorm campaign exposes a systemic gap in how extension marketplaces are governed relative to package registries. The VSX ecosystem currently lacks mandatory binary transparency, reproducible builds, or automated security scanning at the depth applied by npm’s automated malware detection or PyPI’s security tooling. Organizations relying on Open VSX in developer workflows should engage with the Eclipse Foundation’s Open VSX governance to advocate for enhanced pre-publication review, mandatory dependency disclosure at update time, and automated scanning for remote payload fetching patterns.

At the architectural level, development environments should apply the principle of least privilege aggressively. Developer tools—including IDE extensions—should not have unmediated access to cloud credentials, SSH keys, or CI/CD tokens. Secret management tools that provide on-demand credential injection (rather than persistent filesystem storage) limit the blast radius of a compromised extension substantially. Organizations should also consider whether AI coding assistant extensions require network access beyond their stated function, and whether that access should be proxied and inspected.

The observed use of Solana blockchain as a dead-drop C2 resolver is a technique that network-layer detection will struggle to address through simple blocklisting, since it piggybacks on public blockchain infrastructure. Detection should focus on behavioral signals—unusual processes spawned by extension host processes, unexpected keychain access by Node.js, LaunchAgent creation outside of known software installers—rather than purely on network signatures.

CSA Resource Alignment

The GlassWorm campaign illustrates threat patterns addressed across multiple CSA frameworks and guidance documents. Within the MAESTRO framework for agentic AI threat modeling, the campaign exemplifies Layer 1 (Foundation Model) and Layer 6 (Integration Ecosystems) threats: malicious extensions that impersonate AI coding assistant companions introduce adversary-controlled code into the immediate execution environment of agentic AI systems, with direct access to the secrets and credentials those systems use to take actions [4]. As agentic AI tools acquire the ability to install extensions autonomously on behalf of developers, the transitive dependency abuse technique becomes an agentic supply chain risk, not merely a human-facing one.

The Cloud Controls Matrix (CCM) supply chain management domain (STA-01 through STA-09) is directly implicated. CCM STA-04 (Supply Chain Management Policy) requires organizations to maintain documented controls for third-party software dependencies, a control that most organizations have yet to extend to IDE extension ecosystems, though systematic measurement of this gap is limited [5]. CCM STA-09 (Third-Party Audits) supports the recommendation that organizations maintain an approved extension list subject to periodic security review.

The Zero Trust principle of “never trust, always verify” applies directly to extension installation. A Zero Trust posture for developer tooling would prevent automatic installation of transitive dependencies without explicit approval, treating each extension—including those introduced via extensionPack relationships—as an untrusted third party requiring verification before execution [6].

Prior CSA AI Safety Initiative research on developer tool supply chain attacks (March 2026) documented the broader context of AI developer tooling as an attack surface, including VS Code extension campaigns, MCP server compromises, and package ecosystem abuse [7]. The GlassWorm March 2026 escalation represents an intensification of trends documented in that earlier analysis and should be read in conjunction with it.

References

[1] Socket Research Team, “GlassWorm Campaign Uses 72 Malicious Open VSX Extensions to Broaden Reach,” Socket.dev, March 13, 2026. https://socket.dev/blog/glassworm-campaign-uses-72-malicious-open-vsx-extensions (URL returned HTTP 404 as of 2026-03-16; content independently verified via secondary sources [2] and web search aggregates.)

[2] Ravie Lakshmanan, “GlassWorm Supply-Chain Attack Abuses 72 Open VSX Extensions to Target Developers,” The Hacker News, March 14, 2026. https://thehackernews.com/2026/03/glassworm-supply-chain-attack-abuses-72.html

[3] Socket Research Team, “GlassWorm Loader Hits Open VSX via Suspected Developer Account Compromise,” Socket.dev, February 2026. https://socket.dev/blog/glassworm-loader-hits-open-vsx-via-suspected-developer-account-compromise

[4] Cloud Security Alliance, “MAESTRO: A Framework for Agentic AI Threat Modeling,” CSA AI Safety Initiative, 2025. https://cloudsecurityalliance.org/research/working-groups/artificial-intelligence/ (Note: this URL resolves to the general CSA AI Safety Initiative working group index; the MAESTRO framework document may be published separately under the CSA domain.)

[5] Cloud Security Alliance, “Cloud Controls Matrix v4.1,” CSA, 2024. https://cloudsecurityalliance.org/research/cloud-controls-matrix/

[6] Cloud Security Alliance, “Zero Trust Advancement Center,” CSA, 2024. https://cloudsecurityalliance.org/research/zero-trust/ (URL returned HTTP 404 as of 2026-03-16; CSA Zero Trust content may have been reorganized.)

[7] Cloud Security Alliance AI Safety Initiative, “AI Developer Tool Supply Chain Attacks: RCE, Fake Installers, and AI-Promoted Malicious Repos,” CSA Research Note, March 8, 2026. /output/white-papers/CSA_research_note_ai_devtool_supply_chain_attacks_20260308.md

[8] Guardio Labs, “EtherHiding: Hiding ‘Web3’ Phishing Campaigns in the Blockchain,” Guardio Labs Blog, October 2023. https://labs.guard.io/etherhiding-hiding-web3-phishing-campaigns-in-the-blockchain-686c52dc59b0