GlassWorm: The threat that turns IDE extensions into native dropper to invade all your editors

Cybersecurity researchers have discovered a new turn of nut in the campaign known as GlassWorm: a malicious extension for development environments that has incorporated a "dropper" compiled in Zig with the apparent mission of silently infecting all IDEs installed in the developer's team.

The sample appeared on Open VSX under the name specstudio.code-wakatime-activity-tracker, trying to impersonate WakaTime, the tool that records the time you spend programming. The extension is no longer available for download, but the finding made clear a worrying tactic: the inclusion of native binaries compiled along with the extension JavaScript code, which are loaded as Node native supplements and come out of the usual containment of the JavaScript sandbox, thus obtaining access to system-level operations.

In practical terms, the binary accompanying the extension acts as a very discreet piece of "indirection." The files called win.node in Windows or mac.node in macOS are shared bookstores that are loaded on the Node.js runtime and actively seek other IDEs that can accept VS Code-compatible extensions. This search is not limited to Visual Studio Code and its Insiders version: it also covers forks and derivative editors - such as VSCodium - and even some IA-enhanced programming tools that integrate extension compatibility.

Once the binary detects targets, download from an account controlled by the attacker a malicious .VSIX package. That package supplants a very popular legitimate extension called autoimport (the original is published as steoates.autoimport at the Visual Studio Marketplace). The installer writes the .VSIX on a temporary route and quietly installs it on each editor using the command line tools that each IDE provides to install extensions from VSIX files; a flow that any developer can recognize if you have ever installed extensions manually (more information about installation from VSIX is available in the official VS Code documentation: code.visualstudio.com).

The infection cycle does not end with the simple installation: the second extension acts as a more capable dropper. According to the analysis, it avoids running in systems located in Russia, consults Solana's blockchain to get the command and control server (C2) address - a method that takes advantage of public nature and is resistant to the censorship of the blockchains -, collects sensitive data from the development environment, and deploys a remote access trojan (RAT). That RAT continues the attacking chain by installing an extension for Google Chrome designed to steal information stored in the browser.

This evolution of digital crime highlights several critical points for anyone who develops software. First, the extensions are no longer just scripts: they can include native components that operate outside the sandbox and therefore significantly increase the scope of what a malicious package can do in a system. Second, the technique of distributing an installer that silently replicates into multiple IDEs makes development environments an ideal side motion vector for attackers who seek credentials, tokens or secrets with which to pike into other resources.

If you work with tools like WakaTime or install extensions from third-party repositories, precautions should be taken. The incident shows that attackers use legitimate platforms such as Open VSX or public repositories such as GitHub to host and distribute malicious loads in an apparently inoculated way; therefore it is essential to always verify the origin of an extension, review its code when possible and prefer official and reliable sources. To contextualize how these incidents are reported and analysed in the community, specialized media and response teams have documented similar cases in which extensions or packages abuse legitimate services to persist or expand their infection (see coverage in reference sites such as Bleeping Computer or The Hacker News).

If you think your environment could be affected by any of these extensions - for example, if you installed specstudio.code-wakatime-activity-tracker or the extension that supplants to autoimport -, the wise is to make commitment and act quickly. The response should include the uninstallation of suspicious extensions, the search and removal of related native binaries, the verification of extensions installed in all editors and the revision of newly installed browser extensions. It is also essential to rotate any secrets that have been stored or accessible from the access tokens, API keys, repository credentials, etc.) and to revoke those that cannot be guaranteed as uncompromised.

Beyond immediate action, there are medium-term lessons for teams and organizations: minimize the exposure of secrets in the code, use secret and policy managers that reduce unnecessary privileges, regularly audit the permitted extensions in corporate environments and use specialized detection to monitor native binary executions or mass extension facilities. The public nature of certain infrastructure, such as the block of Solana, is being used by attackers to orchestrate C2 communications; understanding these tactics helps to formulate more effective responses (official documentation on Solana in docs.solana.com).

The ecosystem of development is valuable and therefore attractive to cybercriminals. The tools that most facilitate daily work can also become risk vectors if good technical practices are not combined with constant monitoring. In this context, maintaining a critical attitude towards third-party extensions and components, and implementing basic security controls, remains the best defence against campaigns that seek to infiltrate with legitimate appearances.