TL;DR: Malicious and hijacked extensions remain publicly available on OpenVSX even after exposure, while dormant projects and low-reputation publishers can be repurposed as malware distribution paths, according to Knostic. The finding shows that extension marketplaces need runtime trust controls, not just review and takedown workflows, as AI coding assistants increasingly consume them.
At a glance
What this is: Knostic highlights that compromised, dormant, and low-reputation OpenVSX extensions can persist as active malware delivery paths even after exposure.
Why it matters: This matters because AI coding assistants and developers that consume marketplace extensions need controls that assess trust at install and runtime, not only during publication review.
Context
Open marketplace extensions create a supply-chain trust problem when publication, compromise, and install happen faster than manual review and takedown. In AI coding environments, that risk extends beyond human developers because assistants and automation may ingest extensions or related tooling as part of normal work.
The article shows three failure patterns at once: compromised listings that stay live, dormant projects that can be repurposed, and low-reputation publishers that can seed malicious content. That combination makes extension governance a runtime trust issue, not just a marketplace moderation problem.
Key questions
Q: What breaks when malicious extensions remain available after exposure?
A: When compromised extensions remain available, security teams lose the assumption that discovery equals containment. Developers and AI coding assistants can still install the package, which preserves attacker reach inside trusted workflows. The failure is not just malware presence, but the absence of effective revocation, suppression, and runtime blocking across the extension lifecycle.
Q: Why do dormant extensions become a supply-chain risk for AI coding teams?
A: Dormant projects can be repurposed because their historical legitimacy makes a malicious update look routine. That creates a trust gap between the original publisher identity and the current payload. AI coding teams are exposed because rapid installs and automated tool consumption reduce the chance that someone will question an unexpected update.
Q: What are the signs that marketplace trust controls are too weak?
A: Weak trust controls usually show up as higher fraud rates, more suspicious sign-ups, lower completion rates, and declining repeat usage. Another signal is rising customer hesitation during onboarding or checkout, especially when users abandon before verification is complete. If a platform cannot distinguish genuine users from risky ones quickly, trust is already eroding.
Q: Should organisations treat extension review as part of software supply-chain governance?
A: Yes, because marketplace extensions can alter code execution, data access, and developer workflows in the same way other third-party dependencies can. Governance should cover publisher verification, version control, install approvals, and revocation when a package is compromised. The operational question is who owns that control path and how fast it can act.
Technical breakdown
Why extension marketplaces become durable attack surfaces
Open extension ecosystems create a long tail of trust decisions. Once a listing is published, a compromise can survive if the marketplace does not rapidly revoke, quarantine, or flag the package, and users continue to see the extension as available. The abuse pattern is not limited to a single malicious upload. Hijacked developer accounts, reused dormant projects, and innocuous-looking new extensions can all serve as distribution channels. In AI coding environments, that matters because tools may execute or ingest extension content with more privilege than users realise.
Practical implication: Treat marketplace availability as insufficient proof of safety and add runtime trust controls for extension intake.
How dormant and hijacked extensions are reused for payload delivery
A dormant project is attractive because it already has a history, a name, and sometimes an installed user base. Attackers can repurpose that history by publishing an update that appears routine but is actually malicious. Hijacked accounts make the pattern stronger because the package inherits the original trust signal while the contents change. This is a supply-chain problem: the user trusts the publisher identity, but the control plane often does not verify whether the current update is still aligned with that identity. The result is persistence after exposure, not just one-off compromise.
Practical implication: Review account ownership, update provenance, and package change history before allowing extensions into developer environments.
Why AI coding assistants increase extension abuse exposure
AI coding assistants widen the blast radius because they can accelerate the consumption of tools, snippets, and extensions across many users and projects. If an assistant or IDE workflow pulls from a compromised marketplace source, malicious code can spread with little friction. The problem is not that AI changes the existence of the threat. It changes the speed and scale of adoption. That makes provenance, reputation, and behavioral inspection more important than static publisher labels alone.
Practical implication: Apply allowlisting, provenance checks, and install-time inspection wherever AI-assisted development depends on third-party extensions.
Threat narrative
Attacker objective: The attacker wants to persist in trusted developer workflows long enough to distribute malware through routine extension installs.
- Entry occurs when a malicious, hijacked, or repurposed extension is published or remains public in the OpenVSX marketplace.
- Credential or account abuse lets an attacker use a dormant developer identity or compromised publisher profile to push an infected update.
- Impact follows when developers or AI coding assistants install the extension and execute or distribute its payload across projects.
Breaches seen in the wild
- Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
- JetBrains Marketplace AI Plugin Campaign: 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.
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
Extension marketplaces now function as identity trust systems, not just software catalogs. The article shows that a listing's presence in a marketplace does not prove it is safe, current, or still under the control of its original author. That is an identity governance problem as much as a software supply-chain problem, because publisher identity and package integrity have to remain bound over time. Practitioners should treat extension trust as a lifecycle issue, not a one-time approval.
Persistent exposure after public disclosure is the real failure mode here. If a malicious or hijacked extension remains available after it is identified, the control gap is not discovery alone but revocation and quarantine. This is where runtime controls matter more than manual review queues. The specific failure mode is stale trust, where prior legitimacy continues to justify present access to developer environments.
Marketplace reputation is an insufficient signal for AI-assisted development. Low-reputation publishers and generic descriptions can still become effective malware delivery paths, especially when an AI coding workflow normalises rapid installation. The field should stop assuming that install-time review is enough for tools consumed by both humans and machines. Practitioners need governance that can evaluate package trust continuously, not only at publication.
OpenVSX abuse sharpens a broader AI coding supply-chain concept: extension trust debt. That is the accumulation of old, unaudited, or repurposed marketplace trust signals that remain valid long after the underlying package changes. In practice, this means developer tooling, IDE plugins, and AI coding assistants need continuous provenance checks and removal workflows that can outpace attacker republishing.
What this signals
Extension trust debt: marketplace reputation, dormant projects, and inherited publisher identity can outlive the actual safety of the package. For AI-assisted development, that means the decision point moves from publish time to install time and then to runtime inspection.
Security teams should assume that IDE extensions can become a software supply-chain ingress path with the same governance demands as other third-party code. Allowlisting, provenance checks, and post-install monitoring need to sit inside developer security policy, not outside it.
For practitioners
- Implement extension allowlists for developer and AI coding environments Restrict installs to approved publishers, package names, and versions, then block everything else until it passes review.
- Quarantine dormant and repurposed listings Flag extensions with long inactivity gaps, sudden maintainer changes, or unexpected version jumps for manual inspection before use.
- Add install-time provenance checks Verify who published the package, when it changed, and whether the current binary or archive matches the expected source.
- Monitor extension behavior after installation Detect network calls, file writes, credential access, and unexpected code execution in IDE and build-tool contexts.
Key takeaways
- OpenVSX abuse shows that a public marketplace can preserve trust in extensions long after the underlying package becomes unsafe.
- Dormant projects, hijacked publishers, and low-reputation listings all create persistence paths for malware in developer tooling.
- AI coding environments need runtime trust controls, not just manual review of extensions before they are published or installed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Marketplace extensions act as third-party software identities with abuse potential after compromise. |
| NHI-10 — Human Use of NHI | Developers and AI coding assistants consume extensions directly, creating a human-to-machine trust path. | |
| Recommendation — Review third-party extension provenance and restrict installs to approved publishers and versions. Bind developer and assistant extension installs to policy so human approval is required for new sources. | ||
| MITRE ATT&CK | TA0003;TA0006 — Persistence; Credential Access | Hijacked accounts and republished packages show persistence through trusted update channels and possible credential abuse. |
| Recommendation — Map suspicious extension republishing to persistence and credential-access hunting in your detection pipeline. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Extension governance depends on knowing which software is installed and allowed in developer environments. |
| Recommendation — Maintain a complete inventory of approved IDE extensions and remove unsanctioned software assets. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Extension installs and updates are authorization decisions that should be governed explicitly. |
| Recommendation — Apply PR.AA-05 to control who can install extensions and under what approval conditions. | ||
Key terms
- Integration Trust Debt: The accumulated risk created by long-lived, over-scoped, or forgotten SaaS connections that remain active after their original purpose fades. The debt grows when teams treat integration setup as a one-time task instead of a lifecycle-managed identity relationship.
- Hijacked package: A software package that is published or updated under an account or identity no longer under the original maintainer's control. The danger is that the package retains inherited trust while its contents can now be altered for malicious distribution, persistence, or payload delivery.
- Dormant Project Repurposing: A technique where attackers take advantage of an inactive or long-unused package and update it in a way that looks legitimate. The project’s silence becomes cover, making the malicious change harder to spot unless teams monitor publisher behaviour and update patterns closely.
- Runtime Trust: Runtime trust is the idea that access should remain valid only while current context justifies it. Instead of trusting a setup decision indefinitely, teams continuously re-evaluate whether a workload or agent still deserves privilege. This approach is especially important for AI agents that can change behaviour mid-task.
Deepen your knowledge
NHI Foundation Level course covers NHI governance, machine identity security, and secrets management in a practical, practitioner-focused format through the industry's only accredited NHI security programme. It helps security teams build stronger controls for the identity and trust layers that modern development and AI workflows depend on.
Published by the NHIMG editorial team on July 9, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org