In the first week of April 2026, cybersecurity researchers at Aikido flagged a chilling evolution of the GlassWorm campaign — a supply chain attack that has been quietly targeting developers through IDE extensions. This latest variant introduces a Zig-compiled native binary dropper, marking a significant escalation in sophistication and a stark reminder that the tools developers trust most can become their greatest vulnerability.
The Attack: Anatomy of a Developer Supply Chain Compromise
The attack begins innocuously enough. An extension named "specstudio.code-wakatime-activity-tracker" appeared on the Open VSX marketplace, masquerading as WakaTime — a widely popular time-tracking tool used by millions of developers to measure their coding activity. For most developers, installing a WakaTime-like extension is routine, almost reflexive. And that is exactly what the attackers counted on.
Hidden within the extension's package, alongside standard JavaScript code, was a Zig-compiled native binary. Unlike JavaScript, which runs within Node.js's relatively sandboxed environment, a native binary compiled in Zig loads directly into the Node.js runtime and executes with full operating system-level access. This means it can read and write files, access the network, enumerate running processes, and interact with other applications — all without triggering the usual security alerts that JavaScript-based malware might.
Multi-IDE Infection: One Extension, Every Editor
What makes this GlassWorm variant particularly alarming is its multi-IDE propagation strategy. Once the Zig binary executes, its primary objective is to locate every IDE on the developer's machine that supports VS Code extensions. This includes not just Microsoft VS Code and VS Code Insiders, but also forks and derivatives: VSCodium, Positron, and — critically — the new wave of AI-powered coding tools like Cursor and Windsurf.
The binary then contacts a GitHub Releases page controlled by the attacker and downloads a malicious VSIX file disguised as "autoimport," a legitimate and popular extension. This payload is silently force-installed into every detected IDE using each editor's own command-line interface. The developer does not see a notification. There is no consent dialog. The malware simply appears as another installed extension.
Persistence and Exfiltration
The capabilities of the fully deployed GlassWorm payload are extensive. It establishes a persistent remote access trojan (RAT) on the infected machine. It installs a malicious Chrome extension for browser-level surveillance. It communicates with its command-and-control infrastructure through an unconventional channel: a Solana blockchain-based C2 system, which makes traditional network-based detection significantly more difficult. Interestingly, the malware includes geofencing logic that excludes Russian systems from infection.
The exfiltration targets are exactly what you would expect from an attack aimed at developers: SSH keys, API tokens, cloud credentials, environment variables, and source code. For organizations whose developers handle production infrastructure, a single compromised machine can cascade into a full breach.
The Bigger Picture: Extension Marketplaces Are a Systemic Risk
GlassWorm is not an isolated incident. It is the latest and most sophisticated manifestation of a pattern that has been accelerating throughout 2025 and 2026: supply chain attacks targeting developer tools. The npm ecosystem, PyPI, and now extension marketplaces have all become vectors for malicious code distribution.
The fundamental problem is trust architecture. When a developer installs an extension, they are implicitly granting it significant access to their development environment. Extension marketplaces perform some level of review, but the sheer volume of submissions makes thorough vetting impossible. And unlike browser extensions, which operate within relatively strict permission models, IDE extensions often have unrestricted access to the file system and network.
The emergence of AI-powered IDEs like Cursor and Windsurf adds another layer of concern. These tools are designed to give AI deep access to codebases, terminal sessions, and development workflows. An extension that can compromise such an environment gains access not just to static files but to the dynamic context of ongoing development — potentially including proprietary algorithms, unreleased features, and internal documentation.
My Perspective
The GlassWorm campaign should serve as a wake-up call for the entire developer tools ecosystem. We have spent years building security around production deployments — container scanning, runtime monitoring, zero-trust networks — while leaving the development environment itself dangerously under-protected.
I believe three things need to happen urgently. First, extension marketplaces need to implement mandatory code signing and reproducible build verification. If an extension ships a native binary, that binary should be built from auditable source code through a verifiable pipeline. Second, IDEs need to adopt permission models similar to mobile operating systems. An extension that requests file system access, network access, and the ability to install other extensions should trigger explicit user consent, not silent execution. Third, organizations need to treat developer workstations as high-value targets deserving the same security investment as production servers.
The irony of GlassWorm is that it exploits the very tools developers use to build the software the world depends on. Until we secure the development pipeline with the same rigor we apply to the deployment pipeline, attacks like this will continue — and they will get worse.
If you have the extension "specstudio/code-wakatime-activity-tracker" installed, or if you see "floktokbok.autoimport" in any of your IDE extension lists, treat your machine as compromised immediately. Rotate all secrets, revoke all tokens, and audit your recent commits for unauthorized changes.