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.

  1. 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.

  2. 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.

  3. 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 review; the malicious payload lives in whatever the pack currently points at, and the attacker rotates that target without touching the upstream. We expect this form of dead-drop resolver technique to continue evolving.

External-host payload retrieval. Native binaries shipped inside an extension reach out at activation time to fetch the actual payload from a GitHub release page, a private CDN, or a content-addressable host. The pattern was specifically addressed in our Francesca898 writeup (cross-platform droppers using empty GitHub repos as the delivery channel) and again in GLASSWORM (sixteen extensions in 48 hours, all pulling from one GitHub release). Static analysis of the extension itself is mostly empty; the malicious bytes never sit on the marketplace.

Workspace-trust evasion and AI-hook abuse. Extensions declare capabilities.untrustedWorkspaces.supported = true (a positive claim of safety in Restricted Mode) while bundling code that is anything but. A newer variant we caught this week weaponizes Cursor’s hook surface (extension/.cursor/hooks/*.cjs) for XOR-decoded new Function execution that runs only in trusted workspaces, evading the most common sandbox heuristic.

Multi-cloud credential exfiltration. Once a payload runs in a developer environment, the harvest target is no longer just GitHub or npm tokens. Recent waves of the Mini Shai-Hulud worm (unpublished Yeeth research) scrape AWS instance metadata, GCP metadata service, Azure account keys, HashiCorp Vault env vars, and generic API keys, all in a single shot.

What ties all five together is that detection has to happen before the artifact reaches the developer’s machine. Scanning an artifact already on a developer’s machine is too late.

The seven-point IDE security framework

We organize CISO-level IDE security work into seven controls. Although most of these controls are well-understood individually, the combination is where most orgs come up short.

1. Govern the marketplace surface

Treat the IDE marketplace exactly like you treat the package registry. That means:

  • Enforce a minimum extension age before installation. The open-source community is remarkably fast at catching malicious extensions — most campaigns we track get flagged within a day to a week of hitting the marketplace. A policy that blocks extensions newer than 7 days gives the community time to surface malware before your engineers can install them.
  • An explicit allowlist of approved extensions, distributed via your MDM, your dev-environment provisioning script, or VS Code’s extensions.json workspace recommendation surface. The default state should be “allowed extensions only,” not “anything the developer wants.”
  • Vendor-of-record review for high-privilege extensions (anything that contributes terminal commands, language servers, or AI agents). Maintain a list of who you’ve actually verified — publisher domain, GitHub identity, and signing key — and refuse to ship anything not on that list.

2. Constrain the local execution boundary

VS Code’s Workspace Trust is the right idea, badly defaulted. The official guidance is “…open untrusted folders in Restricted Mode.” Most developers have it turned off because half their tooling breaks in Restricted Mode.

The org-level fix is to make that not their decision:

  • Enforce Workspace Trust via managed config. The security.workspace.trust.enabled and related settings can be locked through the IDE’s policy mechanism on Windows and macOS deployments.
  • For new developers, default the trust list to empty. The first time someone opens a freshly-cloned repo, they should hit Restricted Mode.
  • Audit which extensions claim capabilities.untrustedWorkspaces.supported = true against what their bundle actually does. Self-reporting is not enough. To audit: unpack the .vsix archive and inspect extension.js for any logic that only runs inside trusted workspaces. Our recent campaign reports show this is one of the highest-yield evasion techniques in 2026.

3. Watch the network egress

If you only do one thing on this list, do this. The marketplace is too large to allowlist completely, but the network egress from a developer machine is small enough to monitor.

The signals worth alerting on:

  • Outbound to webhook.site, pipedream, requestbin, and other webhook-relay services. Legitimate developers use these for testing; malicious extensions use them as the entire C2 plane. We saw 70+ extensions exfiltrating to webhook.site in a single week.
  • Outbound to api.github.com/repos/*/releases from an editor process to a publisher you didn’t install. Almost every external-payload campaign of the last six months touches a GitHub release.
  • Connections to cloud metadata endpoints (169.254.169[.]254, metadata.google[.]internal, the Azure IMDS path) from anything other than your AWS CLI or your provisioning agent. Mini Shai-Hulud variants from late April pivoted to scraping all three.
  • DNS queries to freshly-registered domains that share a hash family with known IOCs.

A good EDR with custom rules covers most of this. A networking team that owns the dev VPN and turns on full logging covers the rest.

4. Keep credentials off developer machines

Tokens in dev environments are the actual prize. The strongest version of this control is to not have long-lived credentials on developer machines in the first place:

  • Federate cloud access through SSO and short-lived OIDC tokens. AWS IAM Identity Center, GCP Workload Identity Federation, Azure Entra workload identity. Sessions expire on the order of an hour, not weeks, and there is nothing static for an attacker to harvest.
  • Per-org GitHub fine-grained PATs for the cases where a token is genuinely unavoidable, scoped to specific repos and expiring weekly. Classic PATs and broad OAuth scopes are the wrong default in 2026.
  • Where you can, front third-party APIs with a broker your security team controls. Developer machines hold short-lived credentials to the broker; the broker holds the upstream keys and gives you an audit trail of every call. The pattern is well-established for cloud and SaaS APIs: HashiCorp Vault with dynamic secrets, AWS Secrets Manager, an egress proxy you operate.

When credentials do end up on developer machines anyway (and they will), assume they will be read:

  • Nothing sensitive in .env files, plaintext IDE settings, or unattended OS keyrings. The credential-harvesting chains we’ve documented this year all start by reading those exact locations.
  • A token-rotation runbook that your team has rehearsed, not the one a compliance auditor read once. The blast radius of a compromised dev workstation is set by how fast you can rotate.

5. Treat AI assistants as third-party software

GitHub Copilot, Cursor, Codeium, Tabnine, Continue, Aider, Claude Code, and the long tail of AI-powered IDE plugins are not extensions of the IDE. They are independent software vendors with their own security postures, their own credential stores, and their own outbound destinations. Treat them that way:

  • Vendor security review on the same cadence as any other SaaS.
  • Audit logging on what context they exfiltrate. The ones that send full repository content to a third party for “context retrieval” should be on a different security tier than the ones that run a local model.
  • A whitelist of approved AI providers, enforced at the network layer. A class of evasion we’ve caught in 2026 involves extensions that pose as AI assistants but exfiltrate to opaque endpoints with no actual LLM API surface — they work specifically because the AI category is permitted to make outbound calls no other extension can.
  • An AI gateway in front of approved providers, where the operational cost is justifiable. Developer machines never see the upstream key, you get an audit trail of every prompt and tool call, and policy lives in one place. It is not a free lunch: you have to handle streaming responses, track provider API churn, and convince the IDE to point at a custom endpoint. Managed offerings (Cloudflare AI Gateway, Portkey, AWS Bedrock as a frontend) and OSS like LiteLLM make this tractable for a small team. Most orgs we talk to start with one team or one provider and expand from there.

6. Build an IDE incident-response runbook

When (not if) a developer reports a suspicious extension, your team should be able to execute a six-step response without thinking:

  1. Pull the extension’s package.json, extension.js, and any native binaries from the device. The artifact-of-evidence comes off the dev machine before anything else.
  2. Check the extension hash against Open VSX security disclosures and against any commercial threat-intel feed you subscribe to.
  3. Identify the developer’s accessed tokens in the last 30 days from your IdP, source-control, and cloud audit logs.
  4. Rotate every accessible token from step 3. All of them. Time matters more than precision.
  5. Image the workstation if the extension reached payload phase. Memory dump if you can.
  6. Submit the artifact to your scanner partner and to the marketplace’s responsible-disclosure channel.

This list is short for a reason. Long IR runbooks don’t get executed under pressure.

7. Choose your scanner

No org can review every marketplace artifact manually. A scanner is not optional — here’s how to evaluate one.

  • Where does it scan? Pre-install (upstream registry or internal mirror) or post-install (EDR on the developer machine). Pre-install is the more important half — it’s the only position that prevents a bad artifact from ever reaching your engineer. Post-install is cleanup.
  • Does it do attribution, not just detection? In 2026, every major campaign we’ve documented rotates obfuscation between builds while keeping the same payload and infrastructure. A scanner that only matches on file hashes misses the next build. Attribution by behavioral fingerprint — payload host pattern, exfiltration shape, infrastructure reuse — is what catches the campaign, not just the sample.
  • Are its detections published? A scanner whose findings live only in a private dashboard cannot be peer-reviewed and cannot drive marketplace takedowns. The ones worth trusting put their writeups in public.
  • Does it have a direct relationship with the marketplace? Disclosure partnerships with Open VSX and the VS Code Marketplace are the only way a detection turns into an actual removal at scale. A scanner without that relationship is reporting into a void.

Argus is Yeeth’s answer to all four: a pre-publication scanning framework, actor-level attribution through Bane, a public disclosure record, and a direct partnership with marketplaces and registries. The dev-guard extension carries that detection signal back into the IDE itself, so developers see verdicts where they make installation decisions.

Detection signals to instrument today

Quick wins for security teams that want a 90-day plan:

  • Audit rule on git commits authored by claude@users.noreply.github.com that the actual developer did not author. (One of the recent worm waves uses this signature to commit attacker-controlled hooks.)
  • EDR rule for IDE child processes that touch ~/.aws/credentials, ~/.config/gcloud, or the Azure CLI’s token cache.
  • Network rule for outbound HTTPS from code.exe, Code.app, cursor.exe, or any IDE binary to webhook.site, *.pipedream.net, requestbin.com.
  • File-integrity rule on ~/.cursor/extensions/, ~/.vscode/extensions/, ~/.cursor/hooks/ (newer), and .vscode/tasks.json writes triggered by anything other than the IDE update process.

What this means for the next twelve months

We expect three trajectories to dominate IDE security through 2026.

Marketplaces will get aggressive about pre-publication scanning. Open VSX is one example and we expect more to follow.

AI assistants will become the next regulated surface inside dev environments. Once your AI tab can take filesystem actions and call MCP tools, the audit and DLP requirements that already apply to SaaS catch up. CISOs who do not have an opinion on which AI providers are allowed in their dev fleet by Q3 2026 will be backfilling that opinion the hard way.

Workspace-trust enforcement will move from a developer toggle to a managed setting. Restricted Mode is the right architectural primitive; it has been since 2021. The org-level enforcement layer to go with it is what’s missing, and we expect that to ship as part of the next round of MDM-friendly IDE policy controls.

The orgs that come out ahead on IDE security in 2026 will be the ones that already accept all three of these as obvious. We’re available if you want to compare notes: contact@yeethsecurity.com.