A new wave of the GlassWorm malware campaign is targeting software developers by abusing a fake Visual Studio Code extension. Security researchers have identified a Zig-based native dropper embedded in a counterfeit WakaTime activity tracker, capable of silently compromising almost every VS Code–compatible IDE installed on a developer’s workstation.
Malicious WakaTime Look‑Alike Extension Hits Open VSX
The attack was traced to an Open VSX extension named “specstudio.code-wakatime-activity-tracker”. It impersonated the legitimate and widely used WakaTime plugin, which tracks coding time across IDEs. Although the rogue extension has been removed from the repository, any developer who installed it should assume their environment may be compromised.
The fake plugin closely reproduces the core functionality of the genuine WakaTime extension, making manual detection difficult. The key difference is hidden in its activate() function, where the malicious logic is triggered as soon as the extension is loaded by the IDE.
Zig-Based Node.js Dropper: Native Code That Escapes the Sandbox
Upon installation, the extension drops a native binary onto the system: “win.node” on Windows and “mac.node” (a universal Mach‑O binary) on macOS. These files are native Node.js extensions compiled in the Zig programming language.
Unlike typical JavaScript-based extensions, these native modules plug directly into the Node.js runtime and bypass the JavaScript sandbox, granting the attacker full operating system–level access. GlassWorm had previously used compiled native code in extensions, but this campaign shifts the role of the binary: it now acts as a stealthy “proxy” dropper that quietly deploys the main payload and then propagates malicious code to every compatible IDE found on the machine.
Multi‑IDE Infection: VS Code and Compatible Forks at Risk
After execution, the Zig dropper scans the system for all IDEs that support VSIX-based extensions. This includes not only Microsoft Visual Studio Code and VS Code Insiders, but also popular forks and derivative products such as:
- VSCodium
- Positron
- Cursor
- Windsurf
- other AI-assisted and VS Code–compatible editors using VSIX extensions
This approach turns a single malicious installation into a pivot point for mass infection across the entire local development ecosystem, significantly increasing the blast radius of the attack.
From GitHub to Full Compromise: GlassWorm’s Infection Chain
Downloading a Malicious VSIX Package from GitHub
The native Zig dropper downloads an additional VS Code extension file (.vsix) from a GitHub repository controlled by the attackers. This second-stage extension is named “floktokbok.autoimport” and impersonates the legitimate and popular “steoates.autoimport” extension, which has millions of installs on the official Visual Studio Marketplace.
By copying the name and behavior of a well-known package, the attackers reduce the chance that developers or basic security controls will notice anything suspicious.
Silent Installation Across All IDEs and Second‑Stage Capabilities
Once downloaded, the malicious .vsix file is written to a temporary directory and then silently installed into every discovered IDE using each IDE’s command-line installer. This second-stage extension acts as a more feature-rich dropper and surveillance tool with several notable capabilities:
- Geo‑filtering – the malware is configured not to execute on systems with Russian locale or geography, a behavior seen in other regionally selective campaigns.
- Command‑and‑control via the Solana blockchain – the attackers use decentralized blockchain infrastructure to obtain C2 addresses, complicating takedown and blocking efforts.
- Data exfiltration – the extension collects and exfiltrates sensitive information from the developer’s environment to attacker-controlled infrastructure.
- Deployment of a Remote Access Trojan (RAT) – this enables persistent, interactive remote access to the victim machine.
- Installation of a malicious Google Chrome extension – the final stage focuses on theft of browser credentials, cookies, and other sensitive data.
Impact on Developers and Software Supply Chain Security
This campaign is a textbook example of a software supply chain attack targeting developers. By abusing trusted extension ecosystems such as Open VSX and VS Code’s plugin model, GlassWorm can move from a single compromised workstation to broader organizational impact.
Beyond personal data, the most critical risk is exposure of project and infrastructure secrets: repository access tokens, API keys, CI/CD credentials, SSH keys, and cloud platform logins. Public incident reports from prior campaigns (such as SolarWinds, dependency confusion attacks, and malicious npm or PyPI packages) show how compromising development tooling can cascade into large‑scale breaches across enterprises and open source ecosystems.
Given VS Code’s dominant market share and the growing number of compatible AI-enhanced IDEs, similar extension‑based attacks have substantial potential for rapid and stealthy propagation if organizations lack robust extension governance and integrity controls.
Incident Response Steps for Affected Developers
Developers who installed “specstudio.code-wakatime-activity-tracker” or “floktokbok.autoimport” should assume a full compromise of their development environment and act immediately:
- Remove the suspicious extensions from all VS Code–compatible IDEs on the host.
- Run a comprehensive malware and RAT scan using up-to-date endpoint protection tools.
- Change all passwords and rotate all secrets (tokens, SSH keys, API keys, CI/CD credentials).
- Revoke and reissue compromised access tokens in GitHub, GitLab, cloud platforms, and other development services.
- Audit and reinstall Chrome extensions, paying particular attention to unknown or recently added items.
To reduce the risk of similar incidents, organizations should adopt a trusted extensions policy: rely on official marketplaces when possible, verify publisher identity, review install counts and feedback, and regularly audit installed plugins on developer machines. Combined with secure software development lifecycle (SSDLC) practices, secret scanning, least‑privilege access, and anomaly monitoring, these controls significantly strengthen both individual developer security and the overall software supply chain resilience.
