Browser extensions are emerging as supply chain attack vectors

At a glance

What this is: Aikido argues that browser extensions behave like supply chain dependencies because they can inherit broad privileges, update silently, and turn a third-party compromise into enterprise exposure.

Why it matters: IAM and security teams need to govern extension trust, OAuth grants, and device-level inventory because install-time approval alone does not contain downstream compromise.

Context

Browser extensions are third-party code that executes inside a user’s browser with access to sessions, content, and often connected SaaS accounts. That makes them part of the control surface, not just a convenience layer. The problem is that most organisations still govern them as if they were harmless desktop add-ons, which leaves a gap between browser trust and enterprise access control.

The article’s core point is that extension risk is a supply chain problem because compromise can originate upstream in the extension vendor, a maintainer account, or the user’s own device and still land inside enterprise systems. That creates a genuine identity and access governance issue: OAuth grants, browser permissions, and installed extensions become delegated trust relationships that need lifecycle control, not one-time approval.

Key questions

Q: What breaks when browser extensions are not governed in enterprise environments?

A: The main failure is that the browser becomes an unmanaged privilege zone. Extensions can read cookies, session tokens, page content, and tabs, which means they may access authenticated workflows without appearing in IAM or PAM reports. Once permission drift is added, the original approval no longer describes actual risk.

Q: Why do browser extension compromises create enterprise risk even when the target organisation is not directly breached?

A: Because the attacker can exploit a trusted third-party extension or its maintainer to reach the organisation indirectly. Once an extension has access to SaaS accounts or browser sessions, compromise upstream can expose tokens, data, or actions under delegated authority without attacking the target’s perimeter first.

Q: What are the signs that extension trust is failing in an organisation?

A: Look for extensions with broad content access, unmanaged publisher identities, stale allowlists, and OAuth grants that no one can explain. A second warning sign is version or permission drift after approval, because that shows the browser estate is changing faster than governance can track it.

Q: What should organisations do after a browser extension is found to be compromised?

A: Organisations should immediately revoke trust for the affected extension, isolate endpoints where it ran, and review audit logs to identify exposed users and systems. They should also check for related distribution-channel abuse, because compromised extensions may be part of a broader opportunistic campaign. Central control and fast isolation reduce follow-on data theft.

Technical breakdown

Why browser extensions behave like third-party dependencies

Browser extensions are not passive software add-ons. They can read page content, intercept requests, access browser storage, and act on connected accounts if the user consents to broad permissions. That makes them structurally similar to open source dependencies: they are third-party code running with real privileges, and the enterprise often has no direct relationship with the original maintainer. Once an extension is trusted, its security posture becomes part of the organisation’s attack surface. The key technical point is that the browser is the execution boundary, but the trust boundary extends into SaaS and identity systems through OAuth and session tokens.

Practical implication: Treat extensions as governed dependencies and inventory them with the same seriousness as code libraries and privileged integrations.

Why silent extension updates change the risk model

Most browser extension ecosystems update automatically and without meaningful user confirmation. That means the version a user approved at install time is not necessarily the version running today. If an extension becomes malicious after compromise, every installed copy can inherit that change on the next update cycle. This is a classic supply chain property: trust is established once, then reused continuously. Security teams that rely on allowlists or one-off approvals miss the fact that the effective codebase can mutate after deployment. The technical control problem is not just installation, but ongoing integrity and change detection for already-approved extensions.

Practical implication: Build continuous monitoring for extension version changes, permission drift, and post-install behaviour rather than relying on static allowlists.

How OAuth and browser permissions turn extensions into access brokers

The article’s Vercel example shows a common mechanism: a user grants an extension access to SaaS applications, the extension or its vendor backend stores an OAuth token, and later compromise of the extension vendor or the user’s device exposes that token. At that point the extension is no longer just software in the browser. It has become an access broker for enterprise identity. This is where IAM intersects with browser security: delegated access can outlive the original decision to trust the extension, and a compromised endpoint can convert that trust into account takeover or data theft.

Practical implication: Review OAuth grants and extension permissions as delegated identity paths, not as isolated user conveniences.

Threat narrative

Attacker objective: The attacker wants to convert trusted extension access into downstream enterprise account access and data theft without directly breaching the target organisation.

1. Entry begins when a user installs a legitimate-looking browser extension and grants it OAuth access to connected enterprise applications.
2. Credential access occurs when a secondary compromise, such as malware on a vendor or employee device, exposes the extension’s stored token or related access material.
3. Escalation follows because the token lets the attacker operate through the trusted extension relationship rather than through a direct intrusion into the enterprise.
4. Impact is enterprise data theft and broader supply chain exposure, as the attacker inherits access that the organisation believed was limited to a browser add-on.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).

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

Browser extensions are now supply chain assets, not peripheral tools. The governance mistake is assuming that only code repositories and package registries create upstream dependency risk. In reality, extensions can hold OAuth grants, browser privileges, and access to connected SaaS, which puts them in the same trust class as any other third-party dependency. The implication for practitioners is that extension governance belongs in supply chain security, not just endpoint policy.

Silent update behaviour creates a trust window that most enterprise controls do not measure. A user approves one version, but the browser may execute another tomorrow with no meaningful prompt. That breaks the common assumption that install-time approval captures the risk profile of the software in use. The practitioner conclusion is simple: if you cannot observe version drift and permission drift continuously, you do not actually control the extension estate.

OAuth grants to browser extensions are delegated identity relationships and should be treated that way. Once an extension can connect to Google Workspace or similar platforms, the access path extends beyond the browser into identity and session management. This is where NHI governance and human identity governance intersect, because the extension is effectively a third-party actor operating under a user’s delegated authority. Practitioners need to govern those grants as living access paths, not one-time approvals.

Shadow browser extensions create the same discovery problem that shadow IT created for SaaS. If the organisation cannot see what is installed on endpoint browsers, it cannot assess trust, risk, or revocation needs in time. That makes visibility and revocation the core governance issue, not user preference or browser convenience. The practical lesson is that extension inventory has become a control requirement for any programme that cares about identity spillover into the endpoint.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Extension trust is a delegated identity problem: once a browser add-on can reach SaaS accounts through OAuth, the security question shifts from installation approval to revocation discipline. Teams that do not maintain live visibility into extension inventory and publisher change events are already behind the threat.

Browser extension governance should be folded into supply chain policy: the same logic used for package integrity, maintainer trust, and dependency monitoring applies here, but the control point sits in the browser and endpoint estate. Practitioners should align extension review with identity governance, not leave it to user choice.

For practitioners

• Inventory browser extensions across managed devices Establish a continuous inventory of installed extensions, permissions, and publisher identities across all corporate endpoints, including developer machines and high-risk user groups.
• Review OAuth grants to browser extensions Identify which extensions can access Google Workspace, Microsoft 365, and other SaaS platforms, then classify those grants as delegated access paths that need periodic review.
• Block or quarantine high-risk extension classes Use browser and endpoint policy to restrict extension categories that request broad content-reading, request-interception, or account-access permissions.
• Monitor for permission drift and silent updates Alert when an approved extension changes version, publisher, requested permissions, or behavioural profile after initial approval.
• Educate users on extension trust boundaries Train employees that a benign-looking extension can become a supply chain path into enterprise accounts if its maintainer or update channel is compromised.

Key takeaways

• Browser extensions can become enterprise supply chain risks because they sit inside the browser with access to sessions, SaaS accounts, and automatic update paths.
• The article’s main evidence is that trusted extensions can convert upstream compromise into downstream account exposure without a direct breach of the target organisation.
• Continuous extension inventory, OAuth review, and permission-drift monitoring are the controls that change the outcome.

Key terms

• Browser Extension Supply Chain Risk: The risk that a browser extension, its publisher, or its update channel becomes the entry point for compromise. Extensions can inherit powerful browser and SaaS permissions, so a trusted add-on can become a delivery mechanism for token theft, data access, or silent persistence.
• Delegated access path: A delegated access path is the chain of identities, tokens, connectors, and approvals that lets one system act through another. It becomes a governance concern when the path outlives the original approval or can be reused for actions beyond the intended business purpose.
• Silent Update Risk: The security problem created when software changes version or behaviour automatically after approval, without user review at each change. For browser extensions, silent updates can convert a once-benign tool into a malicious one and bypass the decision controls users applied at install time.
• Shadow Extension: A shadow extension is an unmanaged browser add-on that exists outside approved inventory or lifecycle oversight. It creates hidden access paths into SaaS, conferencing, and browser-state data, which means security teams cannot govern what they have not discovered.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in the context of delegated access and lifecycle control. It helps security, IAM, and platform teams align identity governance with the real-world access paths that attackers abuse.