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.
Why dormant extensions become a supply-chain risk for AI coding teams
Dormant extensions are dangerous because they still carry the trust of a known project while their maintenance, ownership, and update path may no longer be actively watched. In AI coding environments, that trust can be exploited at the exact moment when teams are most likely to accept and execute new tooling with minimal friction.
How dormant extensions turn legitimacy into an attack path
A dormant extension often retains an installed base, a recognizable publisher name, and a history that makes future updates seem routine. That creates a trust gap: reviewers and automation may assume continuity even when the effective security posture has changed. If an attacker acquires publishing access, hijacks a dependency, or reactivates a neglected project, the malicious payload arrives through a channel that still looks familiar. This is the same structural problem highlighted by Ledger Connect Kit npm compromise 2023 and the broader extension risk patterns in Secrets in VS Code extensions 2025.
For AI coding teams, the danger is not only the extension itself but the working style around it. Coding assistants, IDE plugins, and repo-driven tooling often consume updates, instructions, and packages quickly, so an unexpected change can be pulled into the workflow before anyone challenges it. A dormant project can therefore become a low-friction delivery path for code execution, credential exposure, or malicious developer-tool behavior, especially when the team assumes that “old and familiar” means “safe enough.”
That risk is amplified when extensions interact with cloud tokens, API keys, CI secrets, or local developer credentials. Once an extension has that reach, a malicious update does not need to be obviously destructive to be harmful, because it can quietly observe, exfiltrate, or redirect trusted operations. AI Coding Agents Security Guide covers why IDE-integrated tools deserve the same supply-chain scrutiny as any other execution path.
Why AI coding teams are a special target
AI coding teams compress decision time. They install plugins, accept helper tools, and trust generated suggestions to keep delivery moving. That speed is productive, but it also reduces the chance that someone will notice an unusual maintainer change, a suspicious permission request, or a release that no longer matches the project’s historical behavior. In practice, the attacker is betting on workflow pressure, not just technical weakness.
These teams also tend to operate across several trust layers at once: the marketplace, the repository, the local IDE, the assistant runtime, and the cloud services behind the workstation. A dormant extension can become the bridge across those layers. If it is repurposed, the malicious update may look like a normal maintenance release while actually introducing a new execution and exfiltration path. Recent cases such as Amazon Q MCP config vulnerability 2026 and Sentry MCP Agentjacking 2026 show how quickly a trusted developer tool can be turned into a credential or command abuse channel.
That is why this is a supply-chain problem, not just a plugin hygiene problem. The question is whether the team can verify that the current payload still matches the original trust relationship. If they cannot, then the historical reputation of the extension is providing cover for a new and possibly malicious function.
Risk and Threat Considerations
Dormant extensions are attractive to attackers because they already sit inside an established trust boundary. A republished or repurposed package can bypass normal skepticism, especially when the extension name, publisher identity, or install history still looks legitimate to developers and automation.
Failure mechanism: The defender trusts continuity, while the attacker changes the payload, ownership, or release channel underneath that apparent continuity. In AI coding environments, rapid installs and automated tool consumption make that change easier to miss and faster to operationalise.
Impact: The result can be credential theft, code injection, data exfiltration, or unauthorized actions through a developer workstation or assistant workflow. Once an AI coding team loads the malicious update, the compromise can spread from a single extension to source control, cloud services, or downstream build systems.
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 addresses the attack and risk surface, while SLSA, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply chain integrity | Dormant extensions are a software supply-chain trust problem. |
| Recommendation — Verify update provenance and require integrity checks before trusting extension releases. | ||
| OWASP ASVS | V13 — Configuration | AI coding tools and extensions depend on trusted configuration and update behavior. |
| Recommendation — Restrict extension permissions and validate changes to developer-tool configuration. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Dormant extensions can be repurposed through trusted third-party publisher paths. |
| NHI-02 — Secret Leakage | Compromised extensions can expose tokens, keys, and other developer secrets. | |
| Recommendation — Assess third-party extension trust before allowing updates into developer workflows. Block extensions from accessing secrets unless the access is explicitly required. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | Trusted extensions need evaluation before release and deployment into AI coding stacks. |
| Recommendation — Test extension updates and reject releases that lack clear provenance or review. | ||
Practitioner Guidance
What to verify: Treat extension history as one signal, not proof of current safety. Verify active maintenance, current ownership, recent release patterns, and whether the extension still needs the permissions it requests.
Decision rule: If an extension is dormant, lightly used, or unmaintained, require explicit review before allowing it into an AI-assisted development environment. If it touches secrets, repositories, or cloud access, treat it as a high-risk dependency until proven otherwise.
What practitioners underestimate: The main danger is not only malicious code, but trust inertia. A familiar name can suppress scrutiny long enough for an attacker to turn a neglected extension into a delivery mechanism.
Practitioner takeaway: For AI coding teams, the control objective is to continuously revalidate trust, because a legacy extension with a good reputation can become risky the moment its payload, publisher path, or update behavior no longer matches that reputation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org