A new GlassWorm-linked supply chain attack abusing the Open VSX Registry, this time via a suspected compromise of a legitimate publisher’s credentials rather than typosquatted packages.
The Open VSX security team assessed the activity as consistent with leaked tokens or other unauthorized access to the publishing pipeline, underscoring how stolen developer credentials can be weaponized to push malicious updates through trusted channels.
On January 30, 2026, four long-standing Open VSX extensions maintained under the “oorzc” namespace received malicious updates embedding the GlassWorm malware loader.
These extensions FTP/SFTP/SSH Sync Tool (v0.5.1), I18n Tools (v1.6.8), vscode mindmap (v1.0.61), and scss to css (v1.3.4) had previously operated as legitimate utilities for more than two years and collectively accumulated over 22,000 downloads on Open VSX prior to the poisoned releases.
While Open VSX shows rounded “K” values in its UI, Socket’s analysis of the underlying counts confirms the combined total exceeds 22,000 downloads, highlighting the potential exposure among developers.
oorzc namespace with four published extensions (Source : Socket).The attack chain hinges on a staged loader introduced in the latest malicious versions across all four extensions.
Malicious VSX Packages Discovered
Each .vsix file contains a nearly identical loader in extension.js that uses AES-256-CBC to decrypt an embedded hex-encoded blob and then immediately executes the decrypted content with eval at runtime.
This design hides the true payload from static inspection, with the critical logic only materializing in memory.
Stage 1 of this decrypted payload performs environment checks to avoid infecting Russian-language and Russia-adjacent systems, using locale, time zone, and UTC offset signals as crude geofencing.
Systems that match Russian indicators are skipped entirely, reflecting typical criminal OPSEC considerations.
If the host passes these checks, Stage 1 then turns to an unusual command-and-control mechanism: it resolves its next-stage configuration from Solana blockchain transaction memos.
Instead of hardcoding C2 domains, GlassWorm uses on-chain memos as a dynamic “dead drop,” allowing the attacker to rotate infrastructure without republishing the extension.
Once the C2 pointer is obtained, the loader focuses its execution path on macOS systems, explicitly checking for Darwin before triggering Stage 2.
That next stage, implemented as a Node.js JavaScript implant, is tailored for data theft and persistence on macOS developer endpoints.
Stage 2 creates a working directory under /tmp/ijewf, aggregates a wide range of sensitive artifacts, compresses them into /tmp/out.zip, and exfiltrates the archive to hardcoded IP-based endpoints via curl.
The collection scope is broad: browser cookies, login databases, and form history from Chromium-based and Firefox-family browsers, wallet-extension data such as MetaMask, desktop cryptocurrency wallet files (including Electrum, Exodus, Atomic, Ledger Live, Trezor Suite, Binance, and TonKeeper), macOS keychain databases, Apple Notes data, Safari cookies, FortiClient VPN configurations, and targeted documents from Desktop, Documents, and Downloads.
Open-Source Ecosystem Exploited
Critically, the implant also harvests developer-related secrets, including ~/.aws credentials and config, and ~/.ssh keys, known_hosts, and configuration files, raising the risk of cloud account takeover and lateral movement inside enterprise environments.
The payload goes further by seeking tokens and secrets used in common developer workflows. It inspects npm configuration for _authToken values and shows behavior consistent with npm token discovery and validation, while also referencing GitHub authentication artifacts.
Compromised GitHub and npm tokens could allow attackers to hijack private repositories, access CI secrets, poison builds, or push tampered releases downstream, extending the blast radius well beyond a single workstation.
This latest activity marks a notable evolution from earlier GlassWorm campaigns first reported in October 2025, which leaned heavily on typosquatting and brandjacking of popular extensions.
In contrast, the current incident abuses an established publisher account with a multi-year history and meaningful adoption signals.
The same “oorzc” publisher also maintains Visual Studio Marketplace listings with thousands of installs, reinforcing that the actor targeted a trusted identity rather than fabricating a new one.
oorzc on Visual Studio Marketplace (Visual Studio Code) listing four extensions (Source : Socket).Socket’s findings focus on the Open VSX ecosystem, and there is no indication in this report that the Visual Studio Marketplace listings themselves were compromised.
After Socket’s January 30, 2026 disclosure, the Eclipse Foundation / Open VSX Registry security team moved quickly.
They removed the malicious releases, deactivated two Open VSX tokens associated with the publisher, and, due to repeated malware hits and numerous versions, removed all versions of oorzc.ssh-tools from the registry and placed it on the Open VSX malware list, while preserving earlier clean versions of the other three extensions.
The response illustrates both the speed and the limits of registry-side defenses: once developer credentials are stolen, trusted distribution paths can be abused until the compromise is detected and tokens are revoked.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.