AI IDE extension supply chain abuse exposes cloud and secret risk

At a glance

What this is: This is a threat-intelligence roundup showing malicious IDE extensions abusing OAuth, environment variables, and remote code execution to turn developer tools into a supply-chain and identity risk.

Why it matters: It matters because IDE extensions can expose cloud credentials, secrets, and delegated access paths that IAM, PAM, and NHI governance often do not monitor as first-class identities.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• 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 extensions hijacking cloud credentials

Context

AI coding extensions are now part of the access layer, not just the productivity layer. When an extension can request OAuth scopes, read process environment variables, and proxy requests through developer tooling, it can become a path to cloud access, secret exposure, and account abuse rather than a harmless add-on.

That creates an identity governance problem as much as a software supply chain problem. The extension itself behaves like a non-human identity with runtime authority, but most organisations do not inventory, classify, or monitor IDE extensions with the same discipline they apply to service accounts, tokens, and privileged workloads.

Key questions

Q: What breaks when a malicious IDE extension can read cloud credentials and environment variables?

A: The main failure is that the editor stops being a neutral tool and becomes a credential collection point. A malicious extension can harvest OAuth refresh tokens, API keys, and workspace secrets, then replay them against cloud or AI services. That turns one workstation into a launchpad for delegated access abuse, quota theft, and downstream compromise.

Q: Why do IDE extensions complicate IAM and NHI governance?

A: They complicate governance because they behave like runtime identities with delegated authority, but they are rarely managed like service accounts or applications. They can request scopes, persist across sessions, and access local secret material without a traditional approval workflow. That makes extension review, token control, and lifecycle offboarding part of identity governance.

Q: How can security teams tell if a developer extension is behaving like malware?

A: Look for auto-activation, frequent polling to unfamiliar endpoints, browser automation, unexpected token reuse, and attempts to read broad environment state. A benign extension usually has a narrow function and a predictable trust boundary. When a plugin starts collecting machine identifiers, secrets, or commands from a remote server, its behaviour no longer matches its stated purpose.

Q: Who is accountable when a marketplace extension steals cloud tokens?

A: Accountability is shared across the marketplace operator, the extension publisher, and the organisation that allowed the extension into a credential-bearing environment. Practically, security leaders own the policy for approval, monitoring, and revocation. If an extension can touch production access, it must be governed like any other third-party identity dependency.

Technical breakdown

OAuth token theft through trusted IDE extensions

Malicious extensions can make OAuth look like ordinary user sign-in while quietly requesting broader scopes than the task requires. In this article's pattern, the extension captures a refresh token with cloud access, then reuses it outside the user's normal workflow to call AI services and cloud APIs. The risk is not only token theft. It is delegated trust abuse, where a plugin inherits the user's authority and then replays it from attacker infrastructure. That makes the extension a shadow identity with durable access until revocation.

Practical implication: review extension scopes, revoke suspicious refresh tokens quickly, and treat IDE plugins as identity-bearing software that must be approved and monitored.

Environment-variable exfiltration turns developer workstations into secret sources

Environment variables often contain API keys, cloud credentials, service URLs, and session material. Extensions that read process.env or equivalent system state can harvest these values without touching protected vaults. In the second cluster described here, the extension sends the full environment snapshot to attacker infrastructure, which is enough to expose secrets even when users believe they are protected by local development controls. The core issue is that workstation telemetry can become credential telemetry when hostile code runs inside the editor.

Practical implication: reduce secret exposure in local environments, block untrusted extensions from workspace and process access, and assume endpoint-level secret discovery must be part of NHI governance.

Auto-activation plus remote code execution creates a persistent attack bridge

The most dangerous pattern is not one malicious function. It is the combination of automatic activation, regular polling, and dynamic code execution. When an extension starts on editor launch, contacts a command server every few seconds, and can eval attacker-supplied content, it gives the operator a persistent control channel into the developer machine. That pattern converts a familiar editor extension into a remote management foothold. From a control perspective, this is indistinguishable from an unmanaged workload with outbound command-and-control capability.

Practical implication: restrict auto-activating extensions, detect outbound polling and eval-like behaviour, and place extension runtime controls into endpoint and application allowlisting.

Threat narrative

Attacker objective: The attacker wants durable access to cloud and AI services through stolen delegated credentials while also harvesting local secrets and preserving control over the developer endpoint.

1. Entry occurs when a developer installs a malicious IDE extension from a marketplace or loads a workspace that triggers automatic activation.
2. Credential access happens when the extension harvests OAuth refresh tokens, environment variables, or other locally available secrets from the editor context.
3. Escalation follows when the stolen token is reused against cloud and AI services, or when the extension accepts attacker-supplied commands and executes them locally.
4. Impact is cloud quota abuse, unauthorized AI API consumption, and exposure of secrets or remote code execution on the developer workstation.

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

IDE extensions are now a non-human identity problem, not just a code hygiene problem: when an editor plugin can request OAuth scopes, read environment variables, and proxy API calls, it behaves like an identity-bearing workload with its own lifecycle risk. Traditional software review catches code quality issues, but it does not model delegated access, refresh-token reuse, or runtime trust abuse. That gap is exactly where malicious extensions operate, so extension governance must sit inside IAM and NHI oversight rather than in developer tooling alone.

Credential-bearing developer tooling creates a secrets blast-radius problem: the danger is not only that one extension is malicious, but that one compromised workstation can surface multiple secret types at once. This is the same fragmentation problem visible in modern secrets management programmes, where controls are split across tools and teams. When a plugin can read local environment state and cloud tokens, the blast radius expands faster than manual review cycles can contain it. Practitioners should treat local development environments as high-value secret stores, not low-risk endpoints.

Auto-activation is a governance assumption failure: many teams assume a marketplace install is inert until a user actively runs a function, yet these findings show code can activate on startup or workspace open. That means the control gap is not just missing detection, but a false belief about when trust begins. The named concept here is extension trust collapse: an add-on inherits runtime authority before the organisation has a chance to evaluate behaviour. Security teams need policy gates before activation, not after compromise.

Cloud and AI service abuse through stolen refresh tokens belongs in the same control conversation as NHI sprawl: the article shows how a single stolen credential can fund AI usage, proxy requests, and identity impersonation across services. That is a workload identity problem, but it is also a governance problem because the credential outlives the user interaction that created it. NHI governance must therefore extend to developer-facing auth flows, especially where tokens can be replayed against AI APIs and cloud platforms. The practitioner lesson is to govern the token, not just the application.

Supply-chain trust now includes the editor runtime itself: extension marketplaces are part of the path to production access, because developers build, test, and authenticate from those environments. A malicious extension can therefore become a bridge between desktop compromise and enterprise cloud compromise without exploiting a traditional vulnerability. That means secure build pipelines, endpoint policy, and identity governance all need to coordinate. The practical conclusion is simple: if the editor can mint or reuse credentials, it is inside your identity perimeter.

From our research:

• 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.
• From our research: Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
• From our research: Explore The 52 NHI breaches Report for recurring credential abuse patterns that show how quickly trusted access becomes attack surface.

What this signals

Extension trust collapse: the core programme risk is the point at which a signed or marketplace-listed extension is treated as benign by default, even though it can read secrets and inherit identity context. That means software allowlisting, endpoint policy, and identity governance need to meet at the same control point, especially when IDE tooling can reach cloud or AI services.

The security signal for practitioners is that developer tools are now part of the credential lifecycle. If your environment still treats editor extensions as low-risk productivity add-ons, you will miss the moment when OAuth consent, environment-variable access, and local automation become one attack path. Map that exposure against the [OWASP NHI Top 10](https://nhimg.org/complete-guide-to-the-2026-owasp-top-10-risks-for-agentic-applications) and your own secret-management controls before a compromised plugin turns into a cloud incident.

For practitioners

• Inventory IDE extensions as identity-bearing software Classify editor extensions by the data and credentials they can touch, then require approval for any extension that can read environment variables, request OAuth scopes, or auto-activate on startup. Tie that inventory to your NHI and secrets governance process so plugin risk is reviewed like other delegated access paths.
• Block broad OAuth grants from developer tooling Restrict cloud and AI OAuth flows used by local developer tools to the minimum scopes required, and revoke refresh tokens immediately when extensions change behaviour. Where possible, isolate development sign-in from production cloud access so a compromised plugin cannot reuse a high-value token across services.
• Detect extension-driven secret exposure at the endpoint Monitor for outbound polling, suspicious browser automation, unexpected use of eval, and large reads of process.env or equivalent environment state. Pair endpoint detections with secrets scanning so leaked credentials are found before they are reused against cloud or AI APIs.
• Separate developer AI access from primary cloud privileges Use dedicated identities, low-trust projects, or constrained tokens for AI coding assistants and local build tools, and avoid linking them to broad cloud permissions. That limits the impact when an extension hijacks an OAuth flow or proxies requests to external infrastructure.
• Add extension behaviour to incident response playbooks If a developer reports suspicious editor behaviour, treat it as a credential and endpoint incident, not a normal software defect. Preserve evidence from the workstation, rotate any exposed secrets, and review recent OAuth consent events, API usage, and extension install history.

Key takeaways

• Malicious IDE extensions can act as identity-bearing software, stealing OAuth tokens, harvesting environment variables, and extending access beyond the user's intent.
• The scale of the risk is amplified by fast attacker response and weak secrets hygiene, which makes exposed credentials and local secret leakage urgent to contain.
• Security teams should govern editor extensions like other third-party access paths, with scope limits, activation controls, endpoint detection, and rapid token revocation.

Key terms

• Non-Human Identity: A non-human identity is a digital credential or account used by software rather than a person. It includes service accounts, API keys, tokens, certificates, and automated agents. The security challenge is managing lifecycle, privilege, and revocation so machine access does not become durable, hidden, or overbroad.
• Refresh Token: A refresh token is a credential that can be exchanged for new access tokens without requiring the user to sign in again. In cloud and AI environments, that makes it powerful and sensitive. If stolen, it can extend access far beyond the original session and bypass normal interactive authentication controls.
• Extension Trust Collapse: Extension trust collapse is the failure that occurs when a marketplace-listed plugin is treated as low-risk even though it can read secrets, access identity context, and run code inside a developer workstation. The trust boundary disappears before the organisation has applied control checks, allowing hidden abuse to look like normal productivity software.
• Delegated Access Abuse: Delegated access abuse happens when software reuses a user's authorised credential or token in ways the user never intended. The access may be valid from the platform's point of view, but the runtime use is malicious. This is a common bridge from local compromise to cloud misuse.

What's in the full article

Knostic's full threat-intelligence report covers the operational detail this post intentionally leaves for the source:

• IOC-level indicators for the BCAI Rosetta extension, including package identifiers, hashes, and affected marketplace metadata
• Static validation details showing how the refresh-token theft, OAuth scope abuse, and proxying behaviour were confirmed from the VSIX
• Per-finding breakdowns for the KoltinSmith cluster, sunsetHighlight, and Musa-DSL, including which cases were malicious versus dangerous by design
• Network fingerprints, callback ports, and attacker domains that help defenders build detection and hunting rules

👉 The full Knostic report covers extension-by-extension indicators, validation notes, and attacker infrastructure details

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and identity lifecycle control. It helps practitioners connect delegated access risk to the broader identity programme they are responsible for.