Malicious IDE extensions expose credentials and CI/CD workflows

At a glance

What this is: This analysis examines how malicious IDE extensions abuse developer trust to access code, secrets, and build workflows, with runtime behaviour emerging as the key detection gap.

Why it matters: It matters because IDEs now sit inside the software supply chain, so IAM, PAM, and NHI teams need controls that cover developer tools, not just production systems.

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.

Context

Malicious IDE extensions are developer tools that request excessive permissions, conceal harmful logic, or trigger background actions after installation. The primary governance gap is that teams still treat the IDE as a safe workspace, even though it has become an execution layer that can read secrets, modify files, and interact with build systems.

This matters for NHI governance because developer environments routinely handle tokens, repository credentials, and CI/CD access paths. Once an extension can act inside that environment, the control problem shifts from endpoint hygiene to identity, privilege, and runtime behaviour inside the software supply chain.

The article frames this as a detection problem, but the deeper issue is trust in extensions that can outlive their apparent purpose. That is a familiar pattern in machine identity risk: access expands quietly, and the blast radius includes code, credentials, and downstream automation.

Key questions

Q: What breaks when an IDE extension is allowed broad runtime permissions?

A: The extension stops being a productivity add-on and becomes an execution path with access to tokens, source code, and build workflows. Broad permissions let a malicious plugin read secrets, modify files, and launch processes without obvious user-visible signs. That is why permission scope must be treated as a security boundary, not a convenience setting.

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 are the warning signs that an IDE extension is abusing trust?

A: Look for extensions that auto-activate, request broad OAuth scopes, proxy traffic through unusual domains, or run hidden background processes. Any extension that mixes login automation, environment-variable reads, and token handling should be treated as a high-risk trust boundary because it can silently exfiltrate secrets.

Q: How should security teams respond when a trusted developer extension starts delivering malware at startup?

A: Treat any extension that executes on startup as a high risk software supply chain event. Remove the extension, identify every dropped binary, and assume the host may have been exposed to remote access tooling or credential theft. Review outbound connections, startup entries, scheduled tasks, and any secrets entered into the extension. Then rotate exposed credentials and hunt laterally across endpoints.

Technical breakdown

Why IDE extension permissions become a security boundary

Modern IDE extensions can request file system access, workspace access, environment variables, network calls, and command execution. Those permissions are not cosmetic because they define what the extension can observe, change, or exfiltrate once installed. Malicious behaviour often hides behind legitimate features such as linters, debuggers, or AI assistants, which makes manifest review necessary but insufficient. The security issue is that the IDE becomes a trusted runtime with access to developer identity, local secrets, and repository material. If the extension can launch processes or write files, it can cross from productivity tooling into supply chain risk.

Practical implication: Treat extension permissions as an access boundary and block any plugin that requests capabilities it cannot justify.

Why static scanning misses malicious IDE extension behaviour

Static inspection looks at package content, declared permissions, and code structure, but it cannot see what the extension does after installation. Malicious extensions can fetch payloads remotely, activate only under certain project conditions, or hide logic in obfuscated JavaScript and encoded strings. That means the dangerous part may not exist in the initial package at all. Behavioural analysis is the stronger control because it observes file writes, unexpected outbound traffic, environment variable access, and child process launches at runtime. In other words, the trust decision cannot end at installation time when the actual risk emerges later in execution.

Practical implication: Pair pre-install review with runtime telemetry so hidden or delayed payloads are still visible.

How MCP and AI assistants expand the extension attack surface

MCP lets extensions connect directly to models, tools, and data sources, which increases the number of paths a malicious extension can abuse. When an IDE extension can reach AI-assisted workflows, it is no longer limited to local code inspection or UI behaviour. It may be able to relay prompts, leak context, or trigger actions that look like normal developer assistance but have security side effects. This creates a broader execution surface because the extension can blend into AI-enabled development activity while still accessing tokens, source files, and repository state. The important shift is that trust now extends from the plugin itself to the tool chain it can reach through MCP.

Practical implication: Restrict MCP-enabled extensions to approved integrations and watch for unusual tool calls or outbound connections.

Threat narrative

Attacker objective: The attacker wants to turn developer tooling into a quiet foothold for stealing secrets and influencing build and delivery pipelines.

1. Entry occurs when a developer installs a malicious IDE extension from a marketplace or alternate registry and grants it broad permissions.
2. Credential access follows when the extension reads environment variables, repository files, or configuration data that contain tokens and secrets.
3. Escalation happens when the extension writes hidden files, runs shell commands, or modifies repository settings to move from observation to action.
4. Impact is the exposure of code, credentials, and CI/CD workflows, which can then be used for supply chain compromise or downstream reuse.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

IDE extensions are now part of the identity perimeter, not just the developer desktop. When an extension can read tokens, write files, and call external services, it is operating inside the same trust boundary as other non-human identities. That makes extension governance an NHI problem as much as an endpoint problem, because the access path is machine-held and workflow-driven. Practitioners should treat the IDE as an execution surface with identity consequences.

Behaviour, not packaging, is what separates a useful plugin from a malicious one. Manifest review and publisher reputation still matter, but they do not capture delayed execution, remote payload loading, or hidden process launch behaviour. This is why runtime monitoring belongs in the control set for developer environments, alongside allowlisting and onboarding checks. The practical conclusion is that static trust signals are only preconditions, not proof of safety.

Secret leakage in developer tooling shows how identity exposure starts before production. The extension layer can surface credentials long before they reach production systems, and that means build and repo governance must be linked to endpoint and developer workflow controls. This is where the identity blast radius concept matters: one compromised plugin can touch credentials, source code, and CI/CD paths in one workflow. Security teams should govern the whole execution path, not just the final deployment target.

Malicious extension governance is a supply chain control problem with NHI properties. A plugin that modifies code or repository settings is not simply a local risk because it can alter what is committed, built, or deployed downstream. That links IDE governance to software supply chain control, secrets handling, and privileged workflow access. The field needs to stop classifying extensions as passive add-ons and start governing them as active identity-bearing components.

Allowlisting is useful only when it is paired with lifecycle controls for extension trust. Verified publishers, periodic review, and usage logging are not separate hygiene tasks, but a lifecycle model for software that can change behaviour after installation. The governance lesson is that trust must be renewed, not assumed. Teams that do not revisit extension permissions and publisher status will continue to miss slow-burn compromise patterns.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Identity blast radius in the IDE is now a governance issue: extensions that can read environment variables, modify repository settings, or launch shell commands are not passive add-ons. They create a machine-held trust path that extends from the developer workstation into code, secrets, and delivery workflows, so extension approval has to sit inside identity governance rather than endpoint hygiene.

Static scanning alone is no longer enough because the risk appears in runtime behaviour, not just in package metadata. Behavioural telemetry, allowlisting, and sandbox validation together give security teams a way to catch extensions that change after installation or hide their payload until a project opens.

When a development tool can access CI/CD credentials, the control question shifts from whether the plugin is popular to whether its behaviour is bounded. That is the same trust problem that appears in other non-human identity estates: access that cannot be scoped, observed, and renewed is access that cannot be safely assumed.

For practitioners

• Build an internal extension allowlist Limit IDE use to verified publishers and vetted plugins, and block installation paths that bypass central approval.
• Monitor extension runtime behaviour Collect telemetry for file writes, shell launches, environment variable access, and outbound connections so suspicious actions are visible after installation.
• Scan developer workflows for exposed secrets Check repository files, config paths, and CI/CD tooling for secrets that an extension could read or copy during normal use.
• Review publisher and version changes continuously Track publisher reputation, sudden permission changes, and update deltas so a once-safe extension does not become trusted by default.
• Educate developers on extension risk signals Train teams to question unexpected permissions, hidden folders, modified .git settings, and unusual network activity in the IDE.

Key takeaways

• Malicious IDE extensions turn developer tooling into an identity and supply chain risk because they can reach secrets, source code, and build workflows.
• The strongest evidence in the article is that suspicious or credential-leaking behaviour appears in a measurable share of real-world extensions, not just in hypothetical cases.
• Runtime monitoring, allowlisting, and developer workflow controls are the controls most likely to reduce exposure when extension behaviour changes after installation.

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.
• Runtime Behaviour Monitoring: Runtime behaviour monitoring is the practice of watching what an identity actually does during execution, not just what it was configured to do. For AI agents, this means tracking tool calls, session activity, data volume, and unusual action sequences so semantic abuse can be detected in flight.
• Extension Allowlisting: Extension allowlisting is the policy of permitting only approved plugins or add-ons on developer systems. It reduces exposure by preventing unknown tools from reading source code, collecting tokens, or opening outbound channels without oversight.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.