Notifications
Clear all
Topic starter
09/07/2026 3:32 pm
TL;DR: A malicious extension, injected JavaScript, or unvetted MCP input can turn a Cursor or VS Code derivative into a privileged execution environment with file-system access, extension modification, and restart-persistent code, according to Knostic. The attack class is old, but AI coding assistants widen the supply chain and workstation blast radius enough that IDE trust now needs explicit governance.
NHIMG editorial — based on content published by Knostic: JavaScript injection attacks against Cursor and other AI coding assistants
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: How should security teams govern AI coding assistants that run extensions and MCP servers?
A: Treat them as privileged development platforms, not lightweight tools.
Q: Why do AI coding assistants create new workstation risk for IAM and PAM teams?
A: They expand the trust boundary into the developer endpoint, where local secrets, repository credentials, and privileged sessions may already exist.
Q: What should security teams get wrong about extension security in developer tools?
A: They often focus on the extension itself and miss the execution context it inherits.
Practitioner guidance
- Lock down extension and MCP intake Allow only approved publishers, pinned versions, and reviewed connectors in developer IDEs.
- Verify bundle integrity on managed IDE builds Track checksums for workbench bundle files and product metadata, then alert on unauthorized edits or checksum drift.
- Separate developer tooling from secret-bearing workflows Minimise local exposure of SSH keys, API tokens, and vault credentials on machines that run AI coding assistants.
What's in the full article
Knostic's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step bundle injection and checksum-bypass mechanics for controlled research environments.
- File-path examples and runtime hooks used to reach local data from the IDE context.
- Detection ideas for bundle edits, rogue extensions, and suspicious outbound traffic from developer tools.
- Practical recommendations for validating extension provenance before installation.
👉 Read Knostic's analysis of AI coding assistant extension abuse and IDE compromise →
AI coding assistants and extension abuse: what security teams need to know?
Explore further
09/07/2026 3:54 pm
IDE trust is becoming a governance problem, not just a developer tooling problem. When AI coding assistants accept extensions, MCP servers, prompts, and rules from external sources, the security boundary shifts from the IDE vendor to the enterprise’s own intake controls. That means supply chain governance now extends into developer workstations, where unvetted components can act like privileged software. Practitioners should manage IDE inputs as controlled dependencies, not convenience features.
A question worth separating out:
Q: Which controls matter most when an IDE compromise could expose secrets and repositories?
A: Prioritise short-lived credentials, tight extension allowlists, and integrity monitoring on IDE bundle files. If local tokens or SSH keys are exposed, an attacker can move from workstation access to repository tampering or downstream system access. Containment depends on limiting what the IDE can reach, read, and persist.
👉 Read our full editorial: AI coding assistants inherit workstation privileges through extension abuse
