The CISO's Guide to IDE Security in 2026 — Yeeth Security
Recognized in the Open VSX Security Hall of Fame
The Malware Factory: GLASSWORM Forensics in Open VSX
Weaponizing Empty Github Repositories with Releases
The Ghost in the Marketplace
Weaponizing Extension Packs with PackRAT
Yeeth - 2025 Year in Review
Secret Scanning with Aho-Corasick
A Deeper Look at RustImplant
SleepyDuck Evolution
WhiteCobra Beginnings
Recognized in the Open VSX Security Hall of Fame
The Malware Factory: GLASSWORM Forensics in Open VSX
Weaponizing Empty Github Repositories with Releases
The Ghost in the Marketplace
Weaponizing Extension Packs with PackRAT
Yeeth - 2025 Year in Review
Secret Scanning with Aho-Corasick
A Deeper Look at RustImplant
SleepyDuck Evolution
WhiteCobra Beginnings
Share
Copy
The IDE has quietly become one of the highest-impact attack surfaces in the modern enterprise. It runs on every engineer’s workstation, can hold the cloud credentials for production, executes arbitrary code in the form of extensions, and — through the AI assistant tab now living next to the editor — talks to a constellation of third-party services on the developer’s behalf. None of those properties are new. The volume and sophistication of attacks targeting them this year is.
This post is a field guide for CISOs and security leaders responsible for that surface. We’re writing it from the position of having spent the last twelve months building our IDE-security detection library, monitoring submissions to the open IDE marketplace, and publishing research on the campaigns we found in the ecosystem. That work culminated in Argus, the scanning platform we now run on top of our security detection library, and resulted in Yeeth Security being recognized by the Eclipse Foundation earlier this month. We see what gets submitted to the open IDE marketplace the second it is available to the public, and we see the playbooks attackers actually use, not the hypothetical ones.
Below is what we think security leadership should be doing about it.
Why IDE security moved up the priority list this year
For most of the last decade, IDE security at the org level meant “make sure VS Code is updated.” That is no longer enough, for three reasons.
Extensions are now the dominant supply-chain delivery channel into engineering . In the corpus we scan, the marked-malicious upload rate to Open VSX tripled in a single week between late April and early May 2026. The volume is not noise. It is the result of threat actors industrializing a specific playbook (clone real publisher namespaces, repackage a near-identical payload across them, exfil to throwaway infrastructure). Two of those actors are running concurrent waves as of this writing.
Developer environments still end up holding production credentials they shouldn’t . It is not the recommended pattern. It is the path of least resistance, and AI scaffolding tooling routinely sets developers down it: .env files generated next to the project, plaintext IDE settings, OS keyrings the editor can reach. Most engineers were never taught the alternatives, and the dangers are not part of the typical onboarding. So GitHub PATs, npm tokens, AWS access keys, Slack OAuth, AI provider keys, and internal service tokens accumulate on developer workstations regardless of policy. The blast radius of a compromised dev workstation is no longer “that one engineer’s laptop” but rather whatever cloud and registry surfaces those credentials happen to reach.
AI assistant integrations expanded the trust surface from “the IDE itself” to “every service the IDE can call on the developer’s behalf” . When an extension can register Cursor hooks, contribute model-context-protocol servers, or chain into the analyst loop of an AI agent, the security boundary stops being the editor process and becomes the assistant’s tool list. A compromised MCP server can silently read files, exfiltrate context, or alter code the developer never authored — all without triggering any of the IDE’s traditional extension-permission prompts.
The 2026 IDE threat landscape, briefly
Five patterns dominate what we are catching this year.
Marketplace squatting at scale. Threat actors register publisher accounts under the names of well-known but unclaimed real authors and ship extensions under those namespaces. Identity reputation is impersonated, the squatted name is what the developer’s autocomplete shows, and the malicious extension’s listing looks more legitimate than the real one. We covered the operational discipline of this pattern in GhostDrop, where 174 GitHub accounts pre-positioned over a five-hour window before the payload phase hit nine days later.
Indirect distribution through extension packs. The extensionPack field in package.json lets a single benign-looking extension drive the silent installation of others. We dissected this technique in PackRAT. The distribution extensions are clean, so they survive marketplace...