A compromise in which a trusted browser, editor, or IDE extension is altered to perform malicious actions after installation. The attack succeeds by abusing legitimacy and convenience, often collecting secrets or altering behaviour inside software developers already trust.
Expanded Definition
An extension supply chain attack occurs when a browser, editor, or IDE extension that users already trust is modified after installation to execute malicious behaviour. In NHI and developer security, the danger is not only the extension package itself but the privileges it inherits from the host application, the filesystem, and the authenticated developer session. This makes the attack materially different from ordinary malware delivery, because it hides inside a workflow tool that is expected to read code, manage secrets, or automate repetitive actions.
Definitions vary across vendors on whether the compromise must occur upstream in the extension repository or can also include post-install tampering by a local attacker. What matters operationally is that the extension becomes a trusted execution path for unauthorized access, exfiltration, or code modification. The OWASP Non-Human Identity Top 10 and the OWASP Non-Human Identity Top 10 both reinforce that identity-bearing tools can become high-value attack surface when they are allowed broad access. The most common misapplication is treating an extension as low-risk software, which occurs when teams approve it based on convenience rather than on the secrets, tokens, and repository access it can reach.
Examples and Use Cases
Implementing extension governance rigorously often introduces friction for developers, requiring organisations to weigh productivity gains against tighter review, pinning, and allowlisting controls.
- A malicious VS Code extension reads environment variables and clipboard contents, then forwards API keys and cloud tokens to an attacker. NHIMG has documented this pattern in Hard-Coded Secrets in VSCode Extensions.
- An IDE plugin with legitimate update access silently adds code to every new project scaffold, creating a persistent backdoor in developer output. This is closely related to broader package compromise trends seen in Shai Hulud npm malware campaign and similar dependency abuse patterns.
- A browser extension used for internal dashboards captures session cookies and reuses them to impersonate a developer in SaaS tooling, bypassing normal login checkpoints.
- An AI coding assistant extension collects prompt content and repository snippets, then leaks sensitive material into remote telemetry. This risk is better understood alongside the Anthropic AI-orchestrated cyber espionage campaign report, where trusted automation became part of the attack path.
Practical defences usually combine signed releases, extension inventorying, version pinning, and strict review of permissions before install. Extension risk also appears in package and action ecosystems, as shown in NHIMG coverage such as the 52 NHI Breaches Analysis, where identity and trust were repeatedly abused across software supply chains.
Why It Matters in NHI Security
Extension supply chain attacks matter because extensions often sit at the intersection of human identity, machine identity, and secrets handling. Once compromised, they can expose tokens, certificates, and API keys, or alter developer actions in ways that are hard to detect through endpoint monitoring alone. This is why NHIMG research repeatedly links supply chain compromise with secrets exposure, including cases where a trusted integration becomes the easiest route to privileged access. In the broader secrets landscape, organisations still take an average of 27 days to remediate a leaked secret, even while 75% report strong confidence in their practices; that mismatch is especially dangerous when the leak originates from a tool developers use every day.
The issue also scales quickly because extensions are widely installed and rarely scrutinised after approval. A compromise in one plugin can spread to many workstations, expose build pipelines, or contaminate source output before defenders notice. Pairing operational review with guidance from CISA cyber threat advisories and NIST SP 800-53 Rev 5 Security and Privacy Controls helps teams translate the term into control decisions around software provenance, access restriction, and monitoring. Organisations typically encounter the damage only after credentials are abused or code has already been altered, at which point extension supply chain attack becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Extension compromise often leads to secret exposure and unauthorized access. |
| NIST CSF 2.0 | PR.IP-3 | Secure software and update integrity are central to extension supply chain risk. |
| NIST SP 800-63 | Extensions can impersonate users by stealing active session material and credentials. | |
| NIST Zero Trust (SP 800-207) | AC-4 | Extension privileges should be limited to prevent lateral access and data leakage. |
| NIST AI RMF | AI-assisted extensions can amplify harm by leaking prompts and sensitive code context. |
Treat extension access as privileged and require stronger assurance for session-bearing tools.
Related resources from NHI Mgmt Group
- Who is accountable when a package token is abused in a supply-chain attack?
- How should security teams handle exposed developer secrets after a supply chain attack?
- What breaks when a supplier account is compromised in a supply chain attack?
- What breaks when a third-party identity is compromised in a supply chain attack?
