Malicious IDE extensions expose credentials and CI/CD workflows

At a glance

What this is: This is an analysis of how malicious IDE extensions abuse developer trust and runtime access to steal credentials or alter code paths.

Why it matters: It matters because IDEs sit inside the software supply chain, so extension governance now affects NHI secrets, developer identity, and CI/CD integrity.

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.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read Knostic's analysis of malicious IDE extension detection and developer risk

Context

Malicious IDE extensions are a supply chain problem disguised as developer productivity tooling. They can request workspace, file system, network, and environment access, then use that access to touch source code, tokens, and build systems in ways traditional endpoint controls often do not inspect.

For NHI governance, the issue is not only whether a plugin is installed, but whether it can behave like an unmanaged workload identity inside the developer workstation. Once an extension can read secrets or launch commands, the trust boundary around the IDE has already been crossed.

The article’s central point is that static review is necessary but insufficient. Runtime behaviour, marketplace provenance, allowlists, and install logging have to work together because malicious extensions can hide intent until after installation, update, or activation.

Key questions

Q: What breaks when IDE extensions are installed without runtime monitoring?

A: Teams lose visibility into what the extension actually does after installation. A plugin can look legitimate in the marketplace yet still read environment variables, write hidden files, or launch child processes that expose secrets or alter code paths. Runtime monitoring is the only way to catch behaviour that manifest review and static scans miss.

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. If an extension can access tokens or modify project files, it can become a distribution point for credential theft or code tampering. That risk is amplified when developers trust third-party plugins more than they inspect the permissions they grant.

Q: What do security teams get wrong about scanning IDE extensions?

A: They often assume a clean manifest means safe behaviour. In practice, many threats hide intent through obfuscation, delayed activation, or remote payload retrieval, so the dangerous action appears only after installation or version change. Security teams need behavioural validation, not just package inspection.

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.

Technical breakdown

Why IDE extension permissions create hidden trust expansion

IDE extensions operate with delegated trust from the developer and the workstation, not from a dedicated security boundary. When an extension requests access to files, environment variables, shell execution, or outbound network calls, it can interact with the same assets that an operator would use manually. The risk is amplified when the extension is updated after approval or pulls remote code at runtime. In identity terms, this is not just software risk, it is access expansion without a corresponding governance event. The security failure is often the mismatch between declared purpose and effective runtime capability.

Practical implication: Treat high-permission extensions as access-bearing entities and review their declared scope before installation.

How malicious extensions hide behaviour from static analysis

Static scanning looks at manifests, source code, and package metadata, but malicious extensions often evade that view through obfuscation, encoded payloads, hidden update paths, or runtime fetches. An extension can appear benign at review time and then activate new behaviour after installation, after a version bump, or only when a target project opens. This is why behavioural inspection matters more than signature matching alone. Runtime telemetry reveals file writes, socket connections, subprocess launches, and unexpected access to environment variables that static inspection cannot reliably prove.

Practical implication: Pair manifest review with runtime telemetry so post-install changes and delayed payloads are visible.

Why MCP-enabled IDEs widen the attack surface

Model Context Protocol connects AI-enabled tools to models and data sources, which makes IDE extensions more capable and more dangerous when misused. A malicious extension can abuse that channel to move data, trigger actions, or interact with services without obvious user prompts. The key issue is that AI-adjacent tooling can make extension behaviour feel normal even when it is operating outside the expected intent of the developer. That shifts the detection problem from code quality to trust and execution monitoring across the IDE, the model connector, and downstream services.

Practical implication: Inspect MCP-connected extensions as runtime integrations, not as ordinary plugins.

Threat narrative

Attacker objective: The attacker wants to turn a trusted developer tool into a covert access path for credential theft, code manipulation, and downstream pipeline compromise.

1. Entry occurs when a developer installs an over-permissioned IDE extension from a marketplace or alternate registry, often trusting publisher reputation rather than runtime behaviour.
2. Escalation follows when the extension reads environment variables, opens sockets, writes hidden files, or spawns child processes that can reach source code, tokens, or build systems.
3. Impact appears when stolen secrets, code tampering, or malicious commands reach repositories and CI/CD workflows, turning the IDE into a supply chain foothold.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Static review creates a false sense of completeness when execution is the real control point. Manifests, publisher profiles, and source inspection matter, but they do not reveal delayed payloads, remote code fetches, or behaviour that changes after approval. The control gap is not visibility alone, it is the absence of runtime verification for software that can act after trust has already been granted. Practitioners need behavioural evidence before they can claim the extension is safe.

Identity blast radius: IDE extensions extend the damage radius from the workstation into code repositories, tokens, and CI/CD pipelines. Once an extension can access environment variables or launch processes, the boundary between developer tooling and production-access paths becomes thin. That is why extension governance belongs in the same conversation as secrets management and privileged access. Practitioners should track extension risk as a supply chain exposure, not a local endpoint event.

The control problem here is unmanaged runtime authority, not just malicious code. A benign-looking extension can still create hidden folders, modify .git settings, or connect to unknown endpoints in ways that alter trust downstream. That means allowlisting, install logging, and version change review are governance controls, but they only work when paired with behaviour monitoring. Practitioners should treat the IDE as an active execution layer.

Developer identity and machine identity are now coupled through extension behaviour. If an extension can read tokens or impersonate workflow actions, it can inherit the identity context of the developer and the device without ever becoming a user account. That coupling raises the value of least-privilege enforcement at the workstation, but it also shows why access decisions must include software provenance. Practitioners should close the gap between developer tooling governance and identity security operations.

From our research:

• 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.
• For a broader NHI lens, the Guide to the Secret Sprawl Challenge shows how hidden credential paths accumulate across development tooling and make governance harder.

What this signals

Identity blast radius: IDE extension governance is now part of secrets management, because a single plugin can bridge developer identity, workstation access, and repository privilege in one execution path. That means security teams should track extension installation, permission drift, and runtime behaviour alongside traditional endpoint events.

With 43% of security professionals already concerned that AI systems may learn and reproduce sensitive information patterns from codebases, the IDE is no longer a neutral editor. Extensions and MCP-connected assistants can move data as easily as they can generate it, so governance has to follow the execution path, not just the UI.

The practical shift is toward continuous trust validation for developer tooling. Internal registries, allowlists, and telemetry should be treated as identity controls for software that can act on behalf of the developer and the machine.

For practitioners

• Build an internal extension allowlist Limit developers to verified publishers and vetted plugins, and block installation paths that bypass internal review. Include approval criteria for workspace access, shell execution, network calls, and environment-variable access.
• 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. Tie alerts to the extension identity, the workstation, and the project context.
• Audit marketplace and registry changes weekly Review new versions, publisher renames, permission drift, and package dependency changes on a fixed cadence. Increase scan frequency during release cycles or after a suspicious extension is detected.
• Log every extension installation centrally Capture who installed what, on which machine, and when, so investigations can connect a compromised plugin to specific repositories or credentials. Keep the record long enough to support incident response and access review.
• Train developers on extension red flags Teach teams to reject obfuscated code, unusual permissions, hidden folders, and unknown endpoints, and require sandbox testing before rollout. Reinforce the rule that convenience tools can be access paths.

Key takeaways

• Malicious IDE extensions are access-bearing software, not harmless productivity add-ons, because they can reach source code, secrets, and build systems.
• Static review alone misses delayed payloads and runtime abuse, so behavioural telemetry is now a core control for developer tooling.
• Extension governance should sit beside secrets management and privileged access, because one compromised plugin can widen identity blast radius across the software supply chain.

Key terms

• Malicious IDE Extension: An IDE extension that uses its installed trust to perform actions beyond legitimate developer assistance. It may read files, access environment variables, run commands, or call remote services in ways that expose code, credentials, or pipeline access. The risk is less about the extension label and more about the authority it gains at runtime.
• Behavioural Analysis: A detection method that judges software by what it does at runtime rather than by what it claims in manifests or source code. For IDE extensions, this means watching file writes, subprocess launches, hidden folders, and network calls to catch delayed or obfuscated abuse that static scanning misses.
• Identity Blast Radius: The range of systems and credentials that can be reached once a trusted tool or identity is compromised. In the IDE context, a malicious extension can extend that blast radius from the workstation into source repositories, tokens, and CI/CD pipelines, making a local plugin issue into a supply chain event.
• MCP: Model Context Protocol is an open protocol that connects AI agents and tools to data sources. In IDE environments, MCP can expand what an extension can reach and trigger, so governance must consider the trust and execution implications of the connection, not just the plug-in itself.

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.

👉 The full Knostic post covers the behavior signals, manual checks, and automated controls in more detail.

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.