Notifications
Clear all
Topic starter
09/07/2026 12:35 pm
TL;DR: Malicious IDE extensions can request excessive permissions, hide payloads, and execute background code inside developer environments, putting source code, credentials, and CI/CD workflows at risk, according to Knostic’s analysis. Static scans alone miss the runtime behaviour that turns trusted plugins into a supply chain foothold, so behavioural monitoring and allowlisting become core controls.
NHIMG editorial — based on content published by Knostic: What This Post on Detecting Malicious IDE Extensions Covers
By the numbers:
- A 2024 academic analysis of 52,880 real-world VS Code extensions found that 5.6% exhibited suspicious or potentially harmful behavior.
- In a 2024 study of 27,261 VS Code extensions, 8.5% were found to be exposed to credential-related data leakage through commands, user input, or configurations.
Questions worth separating out
Q: What breaks when IDE extensions are installed without runtime monitoring?
A: Teams lose visibility into what the extension actually does after installation.
Q: Why do malicious IDE extensions create a supply chain risk for development teams?
A: Because the IDE sits between developers, source code, and build systems.
Q: What do security teams get wrong about scanning IDE extensions?
A: They often assume a clean manifest means safe behaviour.
Practitioner guidance
- Build an internal extension allowlist Limit developers to verified publishers and vetted plugins, and block installation paths that bypass internal review.
- Instrument runtime telemetry for extension behaviour Log file writes, subprocess launches, outbound connections, and access to environment variables so behaviour can be compared against declared functionality.
- Audit marketplace and registry changes weekly Review new versions, publisher renames, permission drift, and package dependency changes on a fixed cadence.
What's in the full article
Knostic's full article covers the operational detail this post intentionally leaves for the source:
- Manifest-level indicators for VS Code and JetBrains plugins that help separate benign from risky extensions.
- Step-by-step manual inspection methods for publisher reputation, obfuscation, and dependency chains.
- Runtime detection ideas for file writes, shell execution, and unusual network traffic inside the IDE.
- The sample behaviour log and the specific red flags used to identify suspicious extension activity.
👉 Read Knostic's analysis of malicious IDE extension detection and developer risk →
Malicious IDE extensions: what do security teams need to catch?
Explore further
09/07/2026 12:40 pm
Malicious IDE extensions are not a plugin hygiene issue, they are an identity trust problem. The extension is granted access that often looks operationally harmless at install time, but behaves like a delegated workload inside the developer environment. That means the governance model has to treat IDE extensions as access-bearing actors, not just code artefacts. Practitioners should align extension oversight to OWASP Non-Human Identity Top 10 and NIST CSF detection and protection functions.
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 extension-driven secret exposure often persists long after initial detection.
A question worth separating out:
Q: How should organisations govern IDE extensions in developer environments?
A: Use allowlists, central logging, and behavioural controls together. Extensions that request workspace, file system, or network access should be reviewed as access-bearing software, and any connection to unknown endpoints or unexpected process launches should trigger investigation before the extension reaches broader use.
👉 Read our full editorial: Malicious IDE extensions expose credentials and CI/CD workflows
