Notifications
Clear all
Topic starter
09/07/2026 9:34 am
TL;DR: A malicious VSIX masquerading as Nx Console ran a pinned external GitHub commit on editor startup with no user prompt, then persisted via a globalState gate and was linked by multiple AV vendors to the Shai-Hulud worm campaign, according to Knostic. The trust model for developer extensions now has to account for remote code execution at activation, not just package provenance.
NHIMG editorial — based on content published by Knostic: LLMjacking-related analysis of the malicious Nx Console VSIX and its supply-chain execution path
By the numbers:
- VirusTotal returned 21 / 66 detections on the exact file.
Questions worth separating out
Q: What breaks when a developer extension can run remote code on startup?
A: The control assumption that an extension is a passive tool breaks immediately.
Q: Why do malicious IDE extensions matter to IAM and NHI teams?
A: They matter because the endpoint often contains the identities that attackers actually want.
Q: How can security teams tell whether an extension has crossed the trust boundary?
A: Look for automatic activation, external fetches at runtime, shell task creation, and persistence markers in local state.
Practitioner guidance
- Constrain extension execution paths Allow only approved publishers and marketplace sources in developer environments, and block extensions that shell out to remote repositories or use startup activation for code retrieval.
- Inventory developer machine credentials Assume an activated malicious extension may have seen SSH keys, npm tokens, cloud credentials, and browser sessions.
- Review local persistence markers Check for application-state keys such as nxConsole.mcpExtensionInstalledSha or similar one-time gates that indicate an extension executed unattended code and then suppressed future prompts.
What's in the full article
Knostic's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact static-analysis workflow used to confirm the VSIX behaviour without executing the package.
- The file-level indicators, activation events, and globalState persistence pattern that operators can hunt for in similar extensions.
- The full IoC list and VirusTotal context for defenders validating whether a suspicious extension has already run.
- The recommended user-side response steps for checking workstation state and identifying whether remote code likely executed.
👉 Read Knostic's analysis of the malicious Nx Console VSIX and supply-chain execution path →
Nx Console supply-chain malware: what IDE teams need to fix?
Explore further
09/07/2026 9:35 am
Extension activation is now an execution boundary, not a UX event: A VSIX that can auto-run shell tasks on startup sits inside the same trust model as other non-human identities that can execute code on behalf of a user. That means the security question is no longer whether the extension looks legitimate, but whether it can cause action before a human makes a decision. Practitioners should treat activation as a privileged event.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
A question worth separating out:
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.
👉 Read our full editorial: Nx Console supply-chain malware exposes the agentic trust gap
