Browser extension risk exposes a widening NHI governance gap

At a glance

What this is: This article examines how malicious browser extensions bypass trust checks and turn browser access into a pathway for NHI exposure.

Why it matters: It matters because identity teams need to govern browser-level permissions, downstream session theft, and extension sprawl as part of NHI and SaaS access risk.

By the numbers:

• A December 2024 campaign targeted at least 35 Chrome extensions.

Context

Browser extensions are small software components that run inside the browser and can inherit access to sessions, cookies, and SaaS workflows. In this article's threat model, they have become part of the identity surface because a malicious extension can operate with user-granted browser permissions while remaining outside conventional app discovery and review.

The governance gap is not just whether a tool is installed, but whether teams can inventory, risk-rank, and constrain what that tool can read or transmit. For NHI programmes, extension risk sits between endpoint control, SaaS access, and session trust, which is why visibility alone is necessary but not sufficient.

The article uses the December 2024 Cyberhaven incident to show that trusted distribution paths and store review do not guarantee safe behaviour. That is a typical failure mode for browser-delivered access, where legitimate installation does not equal legitimate intent.

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 extensions and SaaS sessions create identity risk?

A: Browser extensions and SaaS sessions create identity risk because they operate inside the user’s authenticated context. A compromised extension or hijacked session can observe, alter, or redirect activity without breaking the login itself. Teams should treat the browser as an access layer where identity misuse can happen after authentication has already succeeded.

Q: What are the signs that browser extension controls are failing?

A: Common warning signs include users installing extensions outside policy, extensions running with excessive permissions, unexpected outbound connections to third parties, and risky activity that is not being alerted on. If users can disable or uninstall controls, or if security teams lack visibility into what is installed and active, the extension governance model is already breaking down.

Q: Should security teams treat browser extensions like third-party access?

A: Yes. A browser extension can function like delegated third-party code because it inherits access to the user session and can change behaviour after initial approval. That makes lifecycle control important. Teams should evaluate who publishes the extension, what permissions it requests, and how quickly it can be removed if the trust relationship changes.

Technical breakdown

How malicious browser extensions steal session material

Browser extensions run with permissions that can include access to page content, browser state, and authenticated sessions. If an attacker publishes a malicious extension or hijacks a trusted one, the extension can read cookies, session tokens, and page data before sending them out of band. Store review focuses on installation-time checks, but malicious logic can also arrive through updates after trust has already been established. The architectural problem is that the browser becomes an execution environment with inherited trust, while the extension publisher may no longer be trustworthy.

Practical implication: Treat browser extensions as authenticated code paths that require inventory, permission review, and update monitoring.

Why store review does not close the extension trust gap

A browser store review validates a package against a policy snapshot, not against future behaviour after compromise, takeover, or update abuse. Attackers can register lookalike extensions, compromise an existing publisher account, or push a malicious update into a previously benign extension. That means the control boundary is not the marketplace alone. It is the combination of publisher identity, extension lifecycle, and the permissions granted by users and administrators. In NHI terms, the problem is uncontrolled delegation to code that can change after approval.

Practical implication: Continuously re-evaluate extension trust after publication, not only at initial approval.

Why browser extensions belong in identity governance

Browser extensions now sit between the user and the SaaS applications that carry identity-bearing sessions. They may not be service accounts, but they can still expose the same materials that make NHI compromise damaging: bearer tokens, cookies, and sensitive workflow data. That is why extension governance overlaps with SaaS security and NHI oversight. The practical challenge is not just blocking malware. It is understanding which extensions can amplify a single user session into organisation-wide data exposure when permissions are broad and visibility is weak.

Practical implication: Map browser extensions into the same governance model you use for session-bearing access and high-risk SaaS workflows.

Threat narrative

Attacker objective: The attacker objective was to harvest authenticated browser-session material at scale so downstream access could be abused without re-authentication.

1. Entry occurred when attackers gained initial access through phishing and used that foothold to publish a malicious version of the Cyberhaven Chrome extension.
2. Credential and session material were exposed when the extension exfiltrated cookies, session tokens, and other sensitive data from users.
3. Impact followed as at least 35 Chrome extensions were implicated and about 2.6 million users were affected across the broader campaign.

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.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

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 have become a governance surface, not just a productivity choice. They sit inside the user session and can inherit access to the same cookies, tokens, and SaaS workflows that identity teams work to protect. That means extension risk belongs in NHI governance and SaaS access policy, not only endpoint management. Practitioners need to treat extension approval as a lifecycle decision with downstream identity consequences.

Visibility is the first control, but it is not the control that closes the risk. Obsidian Security's own analysis points to the need to catalogue extensions by risk, permissions, and user reach, which is necessary because browser extensions often leave no external installation signal. The deeper issue is permission sprawl, where a legitimate browser add-on can access more of the identity session than its function warrants. The practitioner takeaway is to govern what extensions can do after discovery, not merely to discover them.

Extension takeover exposes the weakness of store-centric trust models. A package passing marketplace review does not prove that the publisher account, update channel, or future code path remains trustworthy. This is a browser-level analogue of third-party NHI risk, where the identity that delivered the tool is not the identity executing the risk. Teams should re-evaluate how much assurance they place in initial review when the operational threat is post-approval mutation.

Credential and session theft through extensions creates identity blast radius. Once cookies or session tokens are exposed, the compromise often moves beyond a single endpoint into SaaS applications and linked workflows. The governance premise that one user session equals one bounded risk event breaks here, because the browser can multiply access exposure across cloud services. The implication is that identity programmes must account for session portability as a controllable attack surface.

Browser extension risk belongs in the same conversation as NHI and delegated access. The article's broader lesson is that any software component capable of handling session-bearing material needs ownership, lifecycle control, and revocation paths. Without those, teams end up with opaque access paths that look harmless at install time but behave like unmanaged identities at runtime. Practitioners should fold extension governance into identity risk reviews, especially where SaaS access is concentrated.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
• Read next: IVIP and ISPM Buyer's Guide

What this signals

Extension governance is becoming part of identity governance. Browser add-ons can read session-bearing data, which means the control problem is no longer just software allowlisting. Practitioners should map extensions to the same risk tiers they use for privileged access and SaaS administration, especially where broad browser permissions intersect with sensitive workflows.

Permission scope is the real control boundary. The browser store tells you that an extension exists, but not whether its permissions are proportionate to its function or whether its publisher account can be abused later. That is why extension review needs lifecycle thinking, not one-time approval, and why revocation must be operationally simple when trust changes.

For practitioners

• Build a browser extension inventory Catalogue every extension in managed browsers, then sort by permission scope, user count, and whether the extension can touch authenticated SaaS sessions.
• Review extension publisher trust and update paths Check whether extensions are maintained by the original publisher, whether update channels are controlled, and whether account takeover would let malicious code replace benign code.
• Reduce browser permission sprawl Remove extensions that request broad read and write access where the business function does not justify it, especially on browsers used for SaaS administration.
• Monitor for session-bearing data exposure Prioritise detections for cookies, session tokens, and other browser-captured secrets leaving the endpoint through extension activity or suspicious browser traffic.
• Include extensions in identity risk reviews Treat high-reach extensions as part of access governance for cloud applications, because they can amplify a single user session into wider data exposure.

Key takeaways

• Browser extensions can turn ordinary SaaS sessions into identity exposure points when they inherit cookies, tokens, and page access.
• The article's breach example shows how one malicious extension campaign can scale into millions of affected users, which is why visibility alone does not close the risk.
• Practitioners should govern extensions as part of access control, with inventory, permission review, and rapid removal paths when trust changes.

Key terms

• Browser Extension Runtime Trust: The level of confidence an organisation places in a browser extension after it has been installed and is operating inside a user session. For security teams, this trust must be based on observed behaviour over time, not just marketplace approval or permissions at the point of install.
• Session-Bearing Data: Data that can be used to continue an authenticated session, such as cookies and session tokens. When this data is exposed, an attacker may gain access without re-entering credentials, which is why browser capture paths matter in identity governance.
• Extension Takeover: A compromise pattern where an attacker gains control of a previously legitimate browser extension or its publisher account. The extension may then push malicious updates to existing installs, which makes post-approval lifecycle control as important as initial review.
• Permission Sprawl: Permission sprawl is the accumulation of unnecessary or outdated access across identities over time. In cloud and NHI environments, it grows through automation, rapid deployment, and weak offboarding, leaving more standing privilege than the business actually needs.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.