GlassWorm threatens Open VSX by taking advantage of extension units

Security researchers have detected a disturbing variation of the operation known as GlassWorm that attacks the extension ecosystem for code editors, and this time it does so taking advantage of a peculiarity of the Open VSX record. Instead of directly embed a malicious charger in each package, attackers are using the relationship between extensions to transform apparently harmless supplements into delivery vectors into subsequent updates. That means that an extension that seems legitimate at first can, with a simple update, start downloading code linked to Glasgow without the user expecting it. You can read the company's technical report that documented it here: Socket - Open VSX transient GlassWorm campaign.

The mechanism that they exploit is based on how editors install extensions indicated in the metadata: both the extensionPack properties and extensionDependencies in the package.json file cause the editor to also install the listed extensions. This logic, designed to facilitate the developer's experience, becomes dangerous when a malicious actor first publishes a harmless extension and later updates it to declare dependencies to compromised packages. Official documentation of how these manifests work helps to understand the technical detail: VS Code extension manifesto documentation, and the record where many of these extensions are kept is Open VSX.

According to Socket, since the end of January 2026, dozens of malicious extensions were identified in Open VSX that imitated common utility for developers: linters, formateers, code runners and supplements designed for IA programming assistants. The signs of abuse include more aggressive code ofuscation, rotation of payment addresses in the Solana block chain and the use of these transactions as a "dead drop" to resolve command and control servers; techniques that aim to improve the resilience of the attack against traditional mitigation.

In parallel, Aikido researchers have documented a complementary tactic that has been seen in GitHub repositories and npm packages: the insertion of Unicode characters invisible in the source code to hide a charger. Although these characters are not appreciated when reading the file in an editor, the later interpretation allows for decoding and running a first stage that in turn recovers a second stage with tokens exfiltration capabilities, credentials and secrets. Aikido analysis with examples and technical samples is available here: Aikido - GlassWorm returns: unicode attack, and a specific sample of the use of these characters in a commit can be found in this request button: Commit with invisible characters.

The scope of this open source infection was remarkable: Aikido estimated that over a hundred repositories in GitHub were touched in the first week of March 2026, and at least two npm packages with the same technique were detected, which points to a coordinated operation covering different software distribution platforms.

For its part, the research of Endor Labs put on the table another variation of the threat in the npm ecosystem, where dozens of malicious packages published by discounted accounts were found between November 2025 and February 2026. These packages used what is called Remote Dynamic Dependencies: dependencies whose origin is an external HTTP URL instead of the record itself. This capacity allows operators to change the code that is delivered without publishing a new version in the register, which complicates detection and blocking. The Endor Labs report, with its findings and observations on risks of remote dependencies, is here: Endor Labs - Return of PhantomRaven.

The author of these waves was discussed: although some analyzed the campaign as part of the PhantomRaven collective, Endor Labs raised doubts and suggestions that part of the phenomenon might respond to security experiments or research, pointing to alarm signals such as mass data collection, deliberate rotation of accounts and lack of transparency in packages. You can see the context about PhantomRaven and additional analysis in Sonatype's note: Sonatype - PhantomRaven npm malware.

Beyond authorship, there is a clear technical lesson: when a package or extension depends on resources that are not versioned in the register - either remote packages, lockchain addresses that change or transitional dependencies added by updates - the behavior control is left to the publicator. This turns the open source supply into a dynamic attack surface where an apparently banal update can introduce functionalities with extensive permissions and serious consequences.

What does this mean for developers and equipment that build software? First, it requires changing the mentality regarding the implicit trust that is deposited in popular extensions and packages: reputation can be bought or recreated and a legitimate package today can become dangerous tomorrow. Second, it is appropriate to inspect the manifests and the chain of dependencies before incorporating bookstores or extensions into production environments, paying attention to non-standard inputs such as dependencies targeting external URLs, and metadata that add additional packages such as extensionPack or extensionDependencies.

It is also important to protect credentials and tokens with minimum privilege policies and periodic rotation, avoid storing secrets in unprotected environment variables, use private repositories or controlled mirrors where possible, and apply automated supply chain analysis that detects suspicious behaviour. Software analysis and unit scanning tools can help identify packages that incorporate code from sources outside the registry or make unusual calls to the running environment.

Finally, the community and record-keeping have a key role to play: to review and tighten the publishing processes, to deploy mechanisms to detect obfuscation patterns and dynamic dependencies, and to provide clear signals to the user about the origin and scope of what is installed. Open VSX and other repositories have already taken steps to remove malicious extensions, but the technical and operational response must be continuous and collaborative between tool providers, security equipment and developers.

This episode is a reminder that the comfort of modern developer ecosystems - extensions that are installed automatically, dependencies that are solved with a click - brings a security cost if safeguards are not implemented. The defense against campaigns like GlassWorm requires both individual best practices and systemic improvements in how free software and its dependencies are distributed and reviewed.