What breaks when VS Code extensions can self-propagate through registry credentials?

The main failure is trust in the publishing identity. Once an extension can steal tokens and reuse them automatically, the registry becomes a propagation channel rather than a controlled software source. Security teams need to treat publishing credentials as high-impact non-human identities and limit their scope, lifetime, and reuse.

Why This Matters for Security Teams

When a VS Code extension can self-propagate using registry credentials, the problem is no longer just code quality or package hygiene. The extension registry turns into a trust amplification point: one stolen publishing token can seed many malicious installs, updates, or lookalike packages without any human approval in the loop. That is why publishing identities must be treated as high-impact NHIs, not ordinary developer conveniences.

This failure pattern is visible in broader NHI abuse research, including LLMjacking: How Attackers Hijack AI Using Compromised NHIs, where stolen machine credentials enable rapid attacker movement, and in Guide to the Secret Sprawl Challenge, which shows how widely distributed secrets become an attack surface once reuse is normalised. The same logic applies to extension ecosystems: if a token can publish, update, and trigger propagation, the registry is effectively part of the blast radius.

Security teams often misread this as a software supply chain issue only. It is also an identity governance issue, because the publishing credential is now the control plane for distribution. Current guidance suggests treating these tokens as short-lived, tightly scoped, and separately governed from day-to-day developer access. In practice, many security teams encounter propagation chains only after a compromised token has already been used to push malicious updates at scale.

How It Works in Practice

Self-propagation usually succeeds when an extension gains access to a registry token, refresh token, or automation secret that can publish versions or impersonate a trusted maintainer. Once the token is stolen, the extension can copy itself into new packages, update an existing package, or modify metadata to preserve trust. That is why static, long-lived credentials are a poor fit for autonomous or semi-autonomous software behavior.

Operationally, the safer pattern is to move from standing publish rights to just-in-time authorization and ephemeral secrets. That means the build or release workflow requests a narrowly scoped token only when needed, the token expires quickly, and the publishing action is bound to a specific workload identity rather than a person’s shell session. For identity primitives, teams should prefer workload identity over shared secrets, using cryptographic proof of what the release system is, not just what password it knows. Standards-oriented guidance from OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both support least privilege, credential lifecycle control, and separation of duties.

In practice, effective controls usually include:

• Per-release publishing tokens with short TTLs and automatic revocation.
• Separate identities for build, test, sign, and publish steps.
• Policy checks at request time, not just pre-approved role membership.
• Monitoring for unusual package fan-out, version churn, or new maintainer bindings.
• Strong secret storage and rotation, especially for registry automation accounts.

NHIMG research on the 2024 Non-Human Identity Security Report shows that many organisations still struggle with dynamic ephemeral credentials and consistent access management, which is exactly the gap attackers exploit when a token can be reused across automation boundaries. These controls tend to break down when publishing is fully automated from developer laptops or loosely governed CI runners because token reuse becomes indistinguishable from normal release traffic.

Common Variations and Edge Cases

Tighter registry controls often increase release friction, requiring organisations to balance developer speed against the risk of supply chain propagation. That tradeoff becomes sharper in large extension ecosystems, where multiple maintainers, mirrors, and CI pipelines may all need legitimate publish capability.

There is no universal standard for this yet, but current guidance suggests several edge-case rules. If a registry supports organisation-wide automation tokens, those tokens should be segmented by package, environment, and pipeline stage so one compromise cannot fan out across the entire catalog. If extensions can self-update through embedded update logic, teams should treat that behaviour as a privileged capability and review it like remote code execution, not a routine feature. If the ecosystem relies on developer-managed publishing from local machines, the risk is substantially higher because endpoint compromise becomes registry compromise.

For agentic or autonomous release systems, the issue is even more pronounced: a goal-driven agent can chain tools, rotate through accounts, and repeat actions faster than a human reviewer can intervene. In those environments, best practice is evolving toward intent-based authorisation, runtime policy evaluation, and ephemeral workload identity. For additional threat context, Reviewdog GitHub Action supply chain attack and Shai Hulud npm malware campaign show how quickly automated ecosystems can turn secret exposure into broader propagation. The same pattern appears when registry credentials are overpowered, overlong, or reused across unrelated publishing paths.

Related resources from NHI Mgmt Group

• What breaks when a trusted VS Code extension publisher is compromised?
• What breaks when AI tools can execute local code through delegated access?
• What breaks when malicious package installs are allowed to execute code by default?
• What breaks when a compromised package can run code during install or import?