Notifications
Clear all
Topic starter
09/07/2026 9:34 am
TL;DR: The SaassyCode campaign expanded from two malicious VS Code extensions to nineteen, with 17,544 combined installs, a sleeper update strategy, and post-disclosure obfuscation that reduced static detection value, according to Knostic. The case shows why developer-tool marketplaces now need lifecycle-aware identity and update governance, not publication-time scanning alone.
NHIMG editorial — based on content published by Knostic: SaassyCode campaign analysis and the nineteen-extension family
By the numbers:
- StudioBoard had accumulated 1,281 installs by the time of detection and pushed four versions in a single day.
Questions worth separating out
Q: How should security teams handle VS Code extensions that change after installation?
A: Treat the extension as a versioned trust relationship, not a one-time approval.
Q: Why do sleeper extensions create a governance gap for developer environments?
A: Sleeper extensions break the assumption that a trusted package stays in the state that was reviewed.
Q: What do security teams get wrong about extension marketplace scanning?
A: They often treat marketplace approval as proof of runtime safety.
Practitioner guidance
- Reclassify IDE extensions as executable trust objects Inventory every approved extension as a managed non-human identity with publisher, version, install base, and update cadence.
- Gate updates for high-risk developer tooling Require extra review for extensions that can auto-activate, spawn processes, or reach external hosts.
- Segment controls by endpoint operating system Apply tighter policy to Windows developer workstations because the observed payload chain executes there.
What's in the full report
Knostic's full research covers the operational detail this post intentionally leaves for the source:
- Full extension-by-extension breakdown of the nineteen-family cluster, including install counts, versions, and publication dates.
- Static analysis notes for the obfuscated Cluster F variants and the BloxyTask infection chain.
- Indicators of compromise and family fingerprints that defenders can use to hunt for exposed developer workstations.
- Remediation guidance for removing sleeper extensions and reporting them through the VS Code Marketplace process.
👉 Read Knostic's full SaassyCode analysis of the nineteen-extension campaign →
VS Code extension sleepers and update-based payloads: what teams missed?
Explore further
09/07/2026 9:35 am
Sleeper extension publishing is the real governance failure in this campaign. The extension was trusted at install time, then changed behaviour later through an ordinary update path. That means the real identity object is the versioned extension lifecycle, not the marketplace listing, and lifecycle governance must follow the object after onboarding as well as before it.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why developer environments remain exposed to extension-driven abuse.
A question worth separating out:
Q: What should organisations do when developer tooling can execute code on startup?
A: Put the tool inside the same governance boundary as other endpoint-executing identities. Restrict who can install it, require re-review for privilege-changing updates, and monitor for hidden process creation or outbound retrieval. If startup execution is allowed, then its trust must be managed like an active workload, not a passive plugin.
👉 Read our full editorial: SaassyCode shows how VS Code extensions became a sleeper supply chain
