SaassyCode’s VS Code extension campaign shows active malware persistence

At a glance

What this is: This is Knostic’s analysis of the SaassyCode VS Code extension campaign, which continued adding malicious extensions after disclosure and still had one live listing at publication.

Why it matters: It matters because developer extensions can behave like a hidden software supply chain, so IAM and workstation teams need to treat IDE add-ons as an access and execution boundary.

Context

SaassyCode is a malicious VS Code extension campaign that uses legitimate-looking developer tooling as the delivery vehicle for code execution on startup. In this update, the question is not whether the family exists, but whether the campaign can keep scaling after disclosure.

For identity and access teams, the relevant issue is that extension installation, update, and startup behavior create a trust path that sits outside traditional app allowlisting. That matters because code execution in the IDE can become a bridge to browser-stored credentials, developer secrets, and other workstation material.

By June 11, the campaign had moved beyond an isolated malware cluster and into an operational persistence pattern. That is typical of actors who expect defenders to focus on individual samples rather than the ecosystem that keeps reintroducing them.

Key questions

Q: What breaks when a VS Code extension can execute startup commands without user interaction?

A: The control that breaks is the assumption that installed developer tooling remains passive until a user invokes it. If an extension activates on startup, reads hidden configuration, and executes shell commands, then installation itself becomes an execution decision. Teams should treat startup-capable extensions as privileged runtime components, not ordinary plugins.

Q: Why is a VS Code extension child process chain like code.exe to cscript.exe risky?

A: Because that process tree shows the IDE is no longer just rendering code or managing plugins. It is launching a script host that can execute attacker-controlled payloads, which is a strong sign that extension runtime behaviour has crossed into host-level compromise.

Q: What should teams do after a malicious extension is detected?

A: Contain the endpoint, remove the extension, and rotate any secrets that were available in the user session when activation occurred. Then review repository access, package registries, and cloud control planes for follow-on activity. The key question is not only whether the machine is clean, but whether reachable identities have already been abused.

Q: How should organisations govern developer extensions to reduce supply-chain risk?

A: They should treat IDE extensions like software supply-chain dependencies, with approved publishers, process monitoring, and removal workflows for live malicious listings. If an extension can update silently and execute at startup, it belongs in the same risk conversation as other code-distribution paths.

Technical breakdown

How malicious VS Code extensions persist across updates

VS Code extensions can execute automatically when the editor starts, which gives a malicious package a reliable trigger even when the user never clicks anything. In this campaign, the extensions used activationEvents: ["*"] so the payload ran on every startup. That matters because the extension does not need a separate exploit once it is installed. A sleeper variant can ship clean first, build trust, and then deliver the payload in a later update through the normal Marketplace update path. The security boundary is therefore not only the code in the current version but the publisher account, package lineage, and update mechanism behind it.

Practical implication: Treat extension updates as a code-execution channel and review publisher lineage, not just current package contents.

Why the child process chain is a strong compromise signal

The documented chain code.exe → cscript.exe or mshta.exe is not normal developer productivity behavior. In Windows, code.exe is the VS Code process, while cscript.exe and mshta.exe are script and HTML application hosts commonly associated with payload staging. When an IDE spawns those processes, it usually means the extension has crossed from interface logic into external execution. The Boardwalk Plus sample downloaded JavaScript to %TEMP% and then executed it, which fits a loader pattern designed to separate the visible UI from the malicious stage. Static obfuscation may hide indicators, but the process tree remains a high-value detection point.

Practical implication: Alert on VS Code spawning script hosts, especially code.exe to cscript.exe or code.exe to mshta.exe relationships.

Why obfuscation and sleeper versions defeat manual review

This campaign combined several persistence techniques: legitimate UI, delayed malicious activation, publisher-name lookalikes, and in some cases obfuscated JavaScript. That combination reduces the chance that a reviewer will catch the issue by looking only at the Marketplace listing or one version of the package. Sleeper strategies are especially effective in extension ecosystems because the benign version can accumulate installs before the malicious update lands. Once automatic updates are enabled, the user may never notice the transition. The result is not just a bad package, but a package lifecycle that becomes the attack path.

Practical implication: Review extension version history and publisher changes, because the dangerous version may arrive after a benign install base is established.

Threat narrative

Attacker objective: The attacker objective is to keep malicious code resident inside developer workflows long enough to execute payloads and reach workstation-bound credentials or secrets.

1. Entry occurred through a malicious VS Code extension that presented a legitimate Kanban board lure and was installed from the Marketplace.
2. Credential access was not the initial mechanism, but the extension executed attacker-controlled code through normal startup behaviour and could reach developer-stored secrets on the workstation.
3. Escalation came from extension-triggered script execution via cscript.exe or mshta.exe, which moved the activity beyond the IDE into host-level code execution.
4. Impact was persistence across restarts and continued exposure of developer environments through a live extension still available for install.

Breaches seen in the wild

• GlassWorm campaign 2025: GlassWorm hid in VS Code extensions with invisible Unicode and stole npm, GitHub and Open VSX publishing tokens to spread.
• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Extension ecosystems now function as identity-adjacent supply chains: the trust boundary is no longer just the package, but the publisher account, update path, and process behaviour after install. Knostic’s reporting shows that a benign-looking IDE extension can become an execution substrate without any new user action. Practitioners should treat developer tooling as an access surface, not a convenience layer.

Unsigned trust is not the same as managed trust: automatic extension updates and Marketplace distribution create a persistent re-entry point for attackers after initial disclosure. The same family can shift from one version to the next while keeping the same lure and execution chain. That means review workflows focused on single snapshots will systematically miss the operational reality of extension abuse.

Developer workstations need identity-aware detection, not just endpoint hygiene: code.exe spawning cscript.exe or mshta.exe is a governance signal because it shows an extension has crossed into active execution. In practical terms, workstation controls must look for how developer identity, extension provenance, and script-host invocation intersect. The control objective is to reduce the trust granted to extension runtime behaviour.

Supply-chain persistence is the named concept here: the campaign shows how a software distribution channel can keep an attacker present after public exposure. The point is not merely that one malicious extension survived, but that the publishing model itself allowed replacement, variation, and continued install growth. Teams should build response around package lifecycle control, not just malicious sample removal.

What this signals

Supply-chain persistence: this campaign shows that developer tooling can become a recurring delivery path when publishers, updates, and runtime triggers are not governed together. The practical shift is to monitor extension lineage and host behaviour as one control surface, not two separate ones.

A live malicious listing changes the response model because removal is not the same as containment. Teams need to assume that a previously trusted extension channel can be repopulated, so allowlisting and detection logic must account for publisher churn and silent updates.

For practitioners

• Audit extension publisher lineage Review installed extensions for publisher-name variants, sudden publisher changes, and new packages that resemble existing trusted tools.
• Block script-host child processes Flag or block code.exe spawning cscript.exe or mshta.exe, because that child process pattern is not normal VS Code behaviour.
• Check extension version history Do not rely on the current installed version alone. Confirm whether automatic updates introduced a later malicious build after an earlier benign install.
• Remove live marketplace exposure Uninstall any matching Boardwalk family extension, then review Marketplace-approved allowlists so a removed sample does not re-enter through a different publisher account.
• Hunt for workstation secrets exposure Assume a compromised developer machine may expose browser-stored passwords, API keys, session tokens, and other developer secrets that live beyond the IDE itself.

Key takeaways

• The campaign demonstrates that malicious IDE extensions can persist after public disclosure by reusing the same lure, startup trigger, and execution chain.
• One extension remained live at publication, which shows that Marketplace exposure can continue even after related samples are removed.
• Defensive focus should shift from single-sample removal to extension provenance, update history, and script-host child process detection.

Key terms

• Malicious Extension Persistence: Malicious extension persistence is the ability of a marketplace add-on to keep executing after initial discovery, removal pressure, or user complacency. In practice, it is created by update channels, startup triggers, and publisher trust that let the payload reappear or remain active across versions.
• Startup Activation: Startup activation means code begins running automatically when the host application starts, before a user explicitly opens or invokes the extension. That makes the extension’s behaviour closer to an always-on workload than to a passive add-on, which changes governance and containment requirements.
• Script-Host Child Process: A script-host child process is a process such as cscript.exe or mshta.exe launched from another application to run code outside the parent’s normal function. For developer endpoints, it is a high-signal indicator that an extension or plugin has moved from interface behaviour into active execution.
• Technical Lineage: The recorded path that shows where data came from, how it changed, and where it is used. For AI governance, lineage is the evidence trail that helps teams verify whether a model or agent is operating on current and traceable inputs.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.