GlassWorm now uses Zig-compiled native droppers to infect every IDE on a machine
Contents
The GlassWorm campaign has evolved again.
This time it bundles Zig-compiled native binaries inside an Open VSX extension and silently installs a malicious extension across every VS Code-compatible IDE on a developer’s machine.
Aikido Security researcher Ilyas Makari reported the findings in April 2026.
The previous article covered the campaign’s shift to transitive delivery through extensionDependencies.
This new wave goes further—escaping the JavaScript sandbox entirely with OS-level native binaries and invoking each editor’s CLI directly to spread laterally.
It marks a pivot from “attacks within the extension ecosystem” to “cross-IDE attacks through the host OS.”
The fake WakaTime extension
The entry point is an Open VSX extension called specstudio/code-wakatime-activity-tracker.
As the name suggests, it impersonates WakaTime, a popular time-tracking tool for developers.
The UI looks nearly identical to the legitimate extension.
However, this extension ships with platform-specific native binaries inside a ./bin/ directory.
| File | Format | Target |
|---|---|---|
win.node | PE32+ DLL | Windows |
mac.node | Universal Mach-O (x86_64 + arm64) | macOS |
When the extension’s activate function fires, it loads the binary and calls install() before any WakaTime logic runs.
const bw = process.platform === "win32" ? "./bin/win.node" : "./bin/mac.node";
const { install } = require(bw);
install();Why .node files are dangerous
A .node file is a Node.js native addon—a compiled shared library written in C/C++, Rust, or in this case Zig.
When loaded via require(), it binds directly into the Node.js runtime.
Regular JavaScript extension code runs within the V8 sandbox, but native addons are not subject to those constraints.
They can access the filesystem, spawn processes, and make network calls—anything the OS permits.
Because VS Code’s extension security model relies heavily on static analysis of JavaScript code, a compiled binary is effectively a black box.
Why Zig
GlassWorm’s choice of Zig for its dropper (the first-stage loader that downloads and deploys the main malware) is not accidental.
Zig-compiled malware has surged since early 2026, appearing in the VoidLink cloud rootkit (a 9 KB ELF binary) and the CPU-Z 2.19 supply-chain attack.
Several properties make Zig attractive to malware authors.
| Property | Advantage for attackers |
|---|---|
| Cross-compilation built in | Generates Windows/macOS/Linux binaries from a single source. GlassWorm’s win.node and mac.node were likely produced from the same codebase |
| Different binary structure from C/C++ | Heuristic engines and AI-driven detectors trained on C/C++ patterns yield lower detection rates on Zig binaries |
| Static linking, no runtime dependency | Runs standalone on the target machine with no runtime requirement |
| Small binary size | Doesn’t balloon to several MB like Go, making it less suspicious when bundled inside an extension |
| Reverse engineering difficulty | Few analysis tools and limited expertise around Zig slow down incident response |
Debug information left in the macOS binary revealed the project path /Users/davidioasd/Downloads/vsx_installer_zig and username davidioasd. This could indicate incomplete stripping or a deliberate decoy.
How cross-IDE infection works
When install() is called, the binary scans the host filesystem for VS Code-compatible IDEs.
The targets are as follows.
| IDE | Windows | macOS |
|---|---|---|
| VS Code | Known install paths | /Applications/Visual Studio Code.app |
| VS Code Insiders | Ditto | /Applications/Visual Studio Code - Insiders.app |
| Cursor | Ditto | /Applications/Cursor.app |
| Windsurf | Ditto | /Applications/Windsurf.app |
| VSCodium | Ditto | /Applications/VSCodium.app |
| Positron | Ditto | /Applications/Positron.app |
After detecting installed IDEs, it downloads the second-stage payload (the actual malicious code) autoimport-2.7.9.vsix from GitHub repository ColossusQuailPray/oiegjqde Releases.
This VSIX impersonates the legitimate steoates.autoimport extension with the ID floktokbok.autoimport.
The downloaded .vsix is placed in a temporary path, then silently installed into every detected IDE via CLI.
cmd.exe /d /e:ON /v:OFF /c "<ide_path> --install-extension <vsix_path>"An equivalent command runs on macOS.
After installation completes, cleanupVsix() deletes the .vsix file to remove evidence.
graph TD
A["Fake WakaTime extension<br/>installed from Open VSX"] --> B["activate loads Zig binary<br/>via require"]
B --> C["Scan filesystem to detect<br/>all VS Code-compatible IDEs"]
C --> D["Download autoimport-2.7.9.vsix<br/>from GitHub Releases"]
D --> E["Silent install via each<br/>IDE's CLI"]
E --> F["Delete vsix file<br/>to remove traces"]
F --> G["Second-stage extension activates"]
G --> H["Check for Russian locale"]
H -->|Non-Russian| I["Resolve C2 from<br/>Solana blockchain"]
I --> J["Steal credentials and tokens"]
J --> K["Deploy RAT +<br/>Chrome extension"]Second-stage payload behavior
The silently installed floktokbok.autoimport carries the same feature set as previous GlassWorm droppers.
| Feature | Details |
|---|---|
| Locale check | Stops execution on Russian-language systems. A geofencing behavior present since early GlassWorm variants, suggesting the attacker’s location |
| Solana C2 resolution | A dead-drop resolver that retrieves the C2 (command and control) server address from Solana blockchain transaction data. Blockchain immutability makes takedown of C2 information extremely difficult |
| Credential theft | Collects development environment credentials, API tokens, and secrets, then exfiltrates to C2 |
| RAT deployment | Installs a remote access trojan. Also deploys a malicious Chrome extension with keylogging and session cookie theft capabilities |
Because this second-stage extension is installed across all IDEs, removing it from one IDE leaves it running in the others.
IOCs (Indicators of Compromise)
| Type | Value |
|---|---|
| First-stage extension | specstudio/code-wakatime-activity-tracker |
| Second-stage extension | floktokbok.autoimport (autoimport-2.7.9.vsix) |
| win.node SHA-256 | 2819ea44e22b9c47049e86894e544f3fd0de1d8afc7b545314bd3bc718bf2e02 |
| mac.node SHA-256 | 112d1b33dd9b0244525f51e59e6a79ac5ae452bf6e98c310e7b4fa7902e4db44 |
| Payload source | github[.]com/ColossusQuailPray/oiegjqde/releases |
| Debug artifact | /Users/davidioasd/Downloads/vsx_installer_zig |
Differences from the previous wave
The previous GlassWorm wave centered on transitive delivery through the extensionDependencies field. When a front extension was installed, VS Code’s dependency resolution mechanism automatically pulled in the malicious extension—an attack that stayed entirely within the Open VSX marketplace.
What makes this wave fundamentally different is that the execution layer has dropped from the editor extension API to the OS-native layer.
| Aspect | Previous (extensionDependencies) | Current (Zig dropper) |
|---|---|---|
| Infection vector | Editor dependency resolution | Native binary CLI execution |
| Infection scope | Single IDE where installed | All VS Code-compatible IDEs on host |
| Detection target | Manifest dependency audit | Dynamic analysis of compiled binaries |
| Payload delivery | Open VSX registry | GitHub Releases |
| Forensic traces | Dependency extension visible in list | vsix file deleted to destroy evidence |
The inclusion of AI coding agents like Cursor and Windsurf as targets is significant.
These IDEs concentrate API keys, cloud credentials, and project context information, making the data harvested from a single infection far more valuable than what a traditional text editor would yield.
Behaviors that make you vulnerable
This attack impersonates WakaTime—a tool any developer might install. Developers with the following habits face higher risk.
- Installing extensions from Open VSX
IDEs that can’t use the VS Code Marketplace—Cursor, Windsurf, VSCodium—rely on Open VSX as their primary extension source.
The previous GlassWorm wave also targeted Open VSX users.
Open VSX has weaker review processes and less publisher verification than Microsoft’s marketplace - Choosing extensions by name alone
Searching “wakatime” and installing the first result without checking whether the publisher ID matches the legitimate one (WakaTime.vscode-wakatime) - Running multiple VS Code-compatible IDEs simultaneously
Developers who use both VS Code and Cursor, or have Windsurf installed for experimentation, present a wider attack surface.
This attack specifically exploits multi-IDE setups for lateral spread - Never inspecting extension contents
Almost no developer extracts a.vsixto examine its contents.
Native binaries sitting in./bin/go unnoticed beforeactivatefires - Freely installing productivity and theme extensions
WakaTime, GitLens, Prettier, color themes—“nice to have” extensions that aren’t core functionality are prime impersonation targets.
The axios npm hijack showed the same pattern of targeting libraries everyone uses
Supply-chain attacks are not about installing something suspicious—they’re about something you trusted turning out to be compromised.
As covered in the developer tools security roundup, IDEs, extensions, and package managers are all viable targets now.
Response
If you have any indication of having installed specstudio/code-wakatime-activity-tracker or floktokbok.autoimport, Aikido recommends assuming full machine compromise.
Check the extension list in every VS Code-compatible IDE on the machine for floktokbok.autoimport.
If found, remove it from all IDEs, then rotate every credential tied to the development environment—Git credentials, API tokens, secrets stored in environment variables, browser session cookies.
Don’t forget to audit Chrome extensions as well.
We’ve seen this pattern repeatedly with npm supply-chain attacks and Clinejection—attacks targeting developer tool ecosystems are getting more sophisticated fast.
The SANDWORM_MODE worm targeted AI development environments, and macOS infection via AI agents has also been reported.
Native binary-based attacks in particular bypass JavaScript-level static analysis and marketplace review processes.
Checking for a ./bin/ directory before installing extensions, or maintaining an organization-wide extension allowlist, are the practical defenses available today.