Notifications
Clear all
Topic starter
09/07/2026 9:34 am
TL;DR: Malicious VS Code and Cursor extensions can steal OAuth refresh tokens, exfiltrate environment variables, and run attacker-controlled code, turning developer tooling into a cloud access and secret-harvesting channel, according to Knostic's threat intelligence report. The pattern reinforces that IDE extensions now need the same governance attention as other software supply chain and identity-bearing endpoints.
NHIMG editorial — based on content published by Knostic: LLMjacking and malicious agentic supply chain findings in IDE extensions
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Knostic's analysis of malicious IDE extensions hijacking cloud credentials →
AI IDE extensions and secret theft: what security teams should do?
Explore further
09/07/2026 9:35 am
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.
A few things that frame the scale:
- 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.
- Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
A question worth separating out:
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.
👉 Read our full editorial: AI IDE extension supply chain abuse exposes cloud and secret risk
