GlassWorm returns: the supply chain campaign that hides malware with Unicode invisible in repos, packages and extensions

The commitment campaign of the supply chain known as GlassWorm has reappeared with a much wider coordinated wave than initially observed. Researchers from various communities and security companies - including Aikido, Socket, Step Security and the community of OpenSourceMalware- have identified hundreds of packages, repositories and extensions affected on platforms such as GitHub, npm and the extension marketplaces for editors.

In this new phase the scope is remarkable: hundreds of Python and JavaScript repositories have been documented in GitHub, dozens of extensions in VSCode / OpenVSX and several packages published in npm containing code cut or ostrucated by Unicode characters "invisible." The technique of inserting non-printable characters makes it easier for the malicious code to pass unnoticed for surface reviews and automatic filters, because the file may seem legitimate for human eyes and scanners that do not normalize the text.

The joint research points to the same operator behind the different waves: the reports highlight the repeated use of a direction in the blockchain of Solana as a command and control channel, the reuse of infrastructure and payloads with equivalent functionality, and patterns of outflow and persistence comparable between affected projects. These are the details that allow analysts to correlate incidents and suggest that they are not isolated attacks, but a centralized campaign.

Technically, the infection usually starts with the taking of account in GitHub and the introduction of malicious commitments by force-push. From there the attackers publish packages or extensions to records such as npm or OpenVSX. The malware includes a routine that consults Solana's lockchain every few seconds in search of transaction-coded instructions - Step Security researchers documented about 50 relevant transactions between late November 2025 and mid-March 2026 - and those instructions direct the download and execution of a Node.js runtime that unfolds an information thief written on JavaScript.

The objectives of the spy software are clear: data extraction from cryptomoneda coins, credentials, access tokens, SSH keys and development environment artifacts that allow you to pivote and steal additional repositories or credentials. In some previous campaigns, there have also been a number of stranded macos - for example counterfeit customers of hardware purse - and committed extensions that reached unsupported IDEs through OpenVSX, as described by a researcher in the analysis of OpenVSX.

The analysis of the code points to authors who comment in Russian and to a logic that avoids running in systems configured in that language; however, that data alone is not sufficient to attribute responsibility to a specific nation or group with certainty. Attribution requires more operational evidence and corroboration from multiple sources.

If you work with units installed directly from repositories or usually clone projects to implement them, it is appropriate to review technical indicators that analysts have shared. One of them is the presence of a marker variable identified as "lzcdrtfxyqiplpd," which has served as a revealing sign in several committed repositories. Persistence has also been detected using a local configuration file (~ / init.json) and the silent installation of Node.js versions in user directories (like ~ / node-v22 *), in addition to suspicious files with names like i.js in newly cloned projects and commitments whose metadata show strange differences between the date of the author and that of the commitment.

In view of this scenario, containment and mitigation measures go through rotating keys and tokens that may have been exposed, auditing the history of commitments and packages published on their own accounts, and looking for artifacts mentioned in development systems. It is also recommended to enable additional controls on repository accounts: activate the authentication of two factors, review active sessions and authorized SSH keys, and limit tokens with minimum permissions. GitHub and other suppliers publish guides to secure accounts and repositories; for example, GitHub's 2FA documentation is a good starting point: https: / / docs.github.com /... / two-factor-authentication-2fa.

For development teams and platform managers, it is critical to treat the dependencies as potentially unreliable code: validate signatures when they exist, set versions in the lock files, review changes in transitory packages and take advantage of supply chain analysis tools that scan repository and package records. Registration and marketable maintainers should also improve the detection of Unicode ofuscation patterns and strengthen account and publication verification processes.

As for the response to incidents, it is appropriate to keep evidence (logs, build-ups, committed file copies), disconnect infected machines from development networks and make an inventory of secrets that could have been exfiltered. Organizations that depend on open source in production should consider additional prevention controls, such as isolated building environments, reproducible signatures and pipelines that do not implement third-party code without prior review.

GlassWorm reminds us that the security of modern software is not limited to the code we write, but extends to the huge surface that form repositories, packages and third-party extensions. The software supply chain is as strong or as weak as the least protected link, and this campaign shows how actors with practice and resources can move laterally through legitimate tools and services to achieve valuable objectives.

If you want to go into the technical reports and review the indicators published by the teams that have analysed this threat, you can see Aikido's articles on the return of GlassWorm ( Here.), the OpenVSX analysis by Socket ( Here.), and step security's breakdown of the campaign and commitment signals ( Here.). To understand how Solana's transactions can carry memos with instructions, Solana's official documentation on the Memo program is a useful reference: https: / / docs.solana.com /... / programs # memo-program.

The security community and developers must be vigilant and share indicators and mitigation to stop this and other similar campaigns. Collaboration between infrastructure managers, open source project managers and registration providers is essential to reduce the exposure window and raise the protection bar for all.