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.
Editorial analysis by NHI Mgmt Group, based on content published by Knostic: “GitHub Supply Chain Breach: Nx Console 18.95.0 (Analysis)”.
By the numbers:
- The file received 21 / 66 VirusTotal detections, with several vendors applying Shai-Hulud or Shulud family labels.
Key questions
Q: What breaks when an IDE extension can run remote code on activation?
A: The usual trust model breaks because installation no longer means passive presence.
Q: Why do pinned GitHub commits still create supply-chain risk in developer tools?
A: Because a pinned ref only fixes the target, it does not make the target safe.
Q: What signs show a developer extension is behaving like a persistence mechanism?
A: Look for one-time state keys, silent retries after missing dependencies, and install logic that runs again on later activations.
Practitioner guidance
- Restrict extension activation paths Block or review extensions that can trigger shell tasks on startup, especially those that fetch code from external repositories before any user action.
- Audit remote code resolution in IDEs Inventory extensions that use npx, GitHub refs, or other live dependency fetches so remote execution paths are visible before installation.
- Inspect editor-local persistence markers Search affected developer machines for extension state keys that indicate prior remote execution, including nxConsole.mcpExtensionInstalledSha and similar one-time gates.
Bottom line: The core risk is not just a malicious extension package, but a trusted editor plugin that can initiate remote execution as soon as it loads.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
09/07/2026 9:35 am
Activation-time execution is the real trust boundary in IDE supply chains: this case shows that package provenance is no longer enough when an extension can invoke shell execution on load. The extension was not merely installed, it was permitted to act at startup, which collapses the distinction between software distribution and code execution. Practitioners should treat editor activation as a privileged event, because that is where malicious behavior now begins.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should security teams handle malicious IDE extensions in developer environments?
A: Security teams should treat IDE extensions as governed software with access implications, not harmless productivity add-ons. Start by inventorying all extensions, reviewing declared permissions and activation events, and removing anything that executes code, reaches remote services, or touches credentials without a clear business need. Pair that with endpoint monitoring and approval workflows for privileged developer machines.
👉 Read our full editorial: Nx Console supply-chain malware exposes the agentic trust gap