This week, security researchers at Aikido disclosed the latest evolution of the GlassWorm campaign — and it should have every development team paying attention. A malicious IDE extension, disguised as the popular WakaTime productivity tracker, is using a Zig-compiled native binary to silently infect every code editor on a developer’s machine. It is one of the most sophisticated supply chain attacks we have seen targeting the development environment directly.
If your team uses VS Code, Cursor, VSCodium, or any AI-powered coding tool built on the VS Code extension ecosystem, this one is for you.
TL;DR
- The GlassWorm campaign now uses Zig-compiled native binaries hidden inside a fake WakaTime IDE extension to escape JavaScript sandboxes entirely
- Once installed, the dropper scans for every VS Code-compatible IDE on the machine and silently injects a second-stage malicious extension into each one
- The attack chain includes Solana blockchain-based C2 resolution, data exfiltration, a remote access trojan, and a credential-stealing Chrome extension
- Traditional antivirus struggles with Zig binaries due to limited signature coverage — endpoint detection and response (EDR) tooling is essential
- Development teams need extension vetting policies, allowlisting, and runtime monitoring to defend against this class of attack
What Is GlassWorm?
GlassWorm is not new. The campaign first surfaced in March 2025 when Aikido discovered malicious npm packages hiding payloads inside invisible Unicode characters. Since then, it has evolved repeatedly — compromising hundreds of projects across GitHub, npm, and the VS Code marketplace, and delivering everything from cryptominers to persistent remote access trojans.
What makes this April 2026 variant particularly alarming is its sophistication. The attackers have moved beyond JavaScript-based payloads entirely, compiling their dropper in Zig — a systems programming language with minimal antivirus signature coverage — and distributing it as a Node.js native addon that executes with full operating system privileges.
How the Attack Works
The attack begins with a seemingly innocuous extension published to the Open VSX registry under the name specstudio.code-wakatime-activity-tracker. It mimics WakaTime, a legitimate tool that millions of developers use to track coding time. The extension ships two Zig-compiled native binaries alongside its JavaScript code:
- win.node — a PE32+ DLL for Windows systems
- mac.node — a universal Mach-O binary covering both x86_64 and arm64 on macOS
These are not JavaScript files. They are compiled shared libraries that load directly into Node.js runtime and execute outside the JavaScript sandbox with full OS-level access. This is a critical distinction — most developers assume IDE extensions run in a sandboxed environment. Native addons do not.
Stage 1: Cross-IDE Infection
Once the binary loads, its first task is reconnaissance. It scans the developer’s machine for every IDE that supports the VS Code extension format:
- VS Code and VS Code Insiders
- VSCodium
- Cursor
- Positron
- AI-powered coding tools built on the VS Code platform
For each IDE it finds, it downloads a malicious .vsix file from a GitHub Releases page controlled by the attacker and silently installs it using each editor’s own CLI installer. One compromised extension becomes a foothold in every development tool on the machine.
Stage 2: C2, Exfiltration, and RAT Deployment
The second-stage extension is where the real damage happens. It:
- Queries the Solana blockchain to resolve its command-and-control server address — making the C2 infrastructure extremely difficult to take down
- Exfiltrates sensitive data including environment variables, SSH keys, cloud credentials, and API tokens
- Installs a remote access trojan providing persistent backdoor access
- Deploys a malicious Chrome extension that logs keystrokes and dumps session cookies
Notably, the malware skips execution on systems with Russian locale settings — a common indicator of the threat actor’s origin or operational rules of engagement.
Why Zig Makes This Harder to Detect
The choice of Zig is deliberate. Unlike C or C++ binaries, Zig-compiled executables have very limited coverage in antivirus signature databases. Most AV engines have been trained on decades of malicious C/C++ and .NET payloads. Zig produces binaries with different structural patterns, different linking behaviour, and different runtime characteristics.
The binary also hides within normal IDE process activity. When VS Code loads a native addon, it is indistinguishable from legitimate extensions that use native modules — tools like language servers, formatters, and debuggers regularly load compiled binaries. Without dedicated endpoint detection and response (EDR) tooling that monitors process behaviour rather than relying on signatures, this attack can operate undetected for extended periods.
What Your Team Should Do Right Now
1. Check for Indicators of Compromise
If anyone on your team installed specstudio/code-wakatime-activity-tracker or you see floktokbok.autoimport in any IDE extension list, treat the machine as compromised. Rotate all secrets — SSH keys, API tokens, cloud credentials, session cookies — immediately.
2. Audit Your IDE Extensions
Most development teams have no formal policy around IDE extensions. Developers install whatever they like, often without review. This needs to change:
- Maintain an allowlist of approved extensions for your organisation
- Review extensions that ship native binaries — these have OS-level access and should be treated with the same scrutiny as any other software you install on production-adjacent machines
- Prefer verified publishers on the official VS Code Marketplace over Open VSX where possible
- Use VS Code’s extension management policies to restrict installation sources in managed environments
3. Implement Endpoint Detection
Traditional antivirus is not sufficient for this class of attack. EDR solutions that monitor process behaviour — child process spawning, network connections from IDE processes, unexpected file system writes — are essential for catching native binary payloads that evade signature detection.
4. Treat Developer Machines as Production-Adjacent
Developer workstations have access to source code repositories, cloud infrastructure credentials, CI/CD pipelines, and production databases. They are high-value targets. Apply the same security rigour you would to any system with privileged access:
- Enforce endpoint protection and monitoring
- Use hardware security keys or passkeys for authentication
- Segment credentials using secret managers rather than
.envfiles - Implement least-privilege access for cloud and infrastructure credentials
5. Monitor Your Supply Chain
GlassWorm is not an isolated incident — it is part of a broader trend of supply chain attacks targeting the tools developers use daily. Your dependency management, extension policies, and CI/CD pipeline security should be reviewed regularly, not just when a breach makes the news.
The Bigger Picture
The GlassWorm campaign highlights an uncomfortable truth: the developer toolchain is now a first-class attack surface. As AI-powered coding tools proliferate — each one adding new extension points, API integrations, and data flows — the attack surface grows with them. The very tools that make developers more productive also create new vectors for compromise.
This is not a problem any single tool or policy can solve. It requires a layered approach: vetted extensions, endpoint monitoring, credential hygiene, and a security-conscious development culture. At REPTILEHAUS, we help teams build secure development workflows and implement DevSecOps practices that address exactly these challenges — from CI/CD pipeline hardening to developer workstation security policies.
The days of treating the IDE as a trusted, safe environment are over. Your development environment deserves the same security posture as your production infrastructure.
Need help securing your development pipeline? Get in touch — our team specialises in DevSecOps, security audits, and building secure-by-default development workflows.
📷 Photo by Jakub Żerdzicki on Unsplash
