TL;DR: Malicious browser extensions are increasingly used to compromise employee browsers by abusing legitimate installs, update channels, and store trust checks, according to Push Security. Existing IAM and endpoint controls often miss this browser-level identity layer, so allowlisting, inventory, and change monitoring now matter more than static review alone.
At a glance
What this is: This is a practitioner guide on malicious browser extensions and the finding that browser extension management has become an identity and trust problem, not just a store-review problem.
Why it matters: IAM and security teams need to treat browser extensions as governed runtime entities because approved software can turn malicious after installation, bypassing assumptions in endpoint and identity controls.
Context
Malicious browser extensions create a governance gap because the trust decision happens at install time, but the risk can change after approval. A browser extension may begin life as a legitimate tool, then become malicious through a developer account compromise, a purchased extension, or a poisoned update.
That breaks the assumption that approval, store checks, and endpoint controls are enough to govern browser behaviour. For identity programmes, the extension becomes a browser-level control plane that needs inventory, lifecycle oversight, and change monitoring rather than a one-time allow-or-block decision.
Push Security frames the problem as operational, not theoretical: attackers can wait until an installed extension flips from benign to malicious, then use the update path to compromise every browser where it is deployed.
Key questions
Q: What breaks when a browser extension changes behavior after approval?
A: The trust model breaks because approval was based on an earlier version of the code, not on the extension’s current runtime behavior. A benign extension can later load remote scripts, capture session material, or redirect traffic without triggering a fresh consent decision. Security teams need continuous monitoring of updates, permissions, and network destinations, not a one-time allowlist.
Q: Why do malicious browser extensions evade store review and static analysis?
A: They evade review because attackers hide malicious behaviour until after the extension is already trusted, often by using obfuscated code or delayed activation. Store approval checks the submitted package, but it cannot guarantee that later updates or runtime behaviour will remain safe.
Q: How should security teams govern browser extensions in zero trust environments?
A: Security teams should treat browser extensions as privileged software with access to user data, sessions, and web content. The safest approach is policy based control, with whitelisting for approved extensions, blacklisting for known risky ones, centralized management, and continuous review of extension permissions. Masking sensitive fields and obfuscating inputs also reduce the chance that extensions can read or misuse confidential data.
Q: How do organisations reduce the chance that a malicious extension spreads across browsers?
A: They should block unapproved extensions, disable broad sync where appropriate, and watch for suspicious change events before the extension reaches more browsers. The key is to interrupt distribution at the browser level, because store removal alone does not necessarily remove an installed extension.
Technical breakdown
Why extension stores do not solve post-approval risk
Browser extension stores validate uploads at a point in time, but they do not make the extension trustworthy for its entire installed life. Attackers exploit that gap by publishing a benign extension, buying an existing one, or phish-capturing a developer account, then pushing a malicious update later. Static code analysis also struggles when malicious code is obfuscated, dynamically compiled, or hidden until runtime. The security problem is therefore not just distribution, but trust decay after approval.
Practical implication: Treat store approval as an initial trust signal, not as lifecycle assurance.
How malicious extensions bypass static checks and user controls
The article describes a common pattern where bad behaviour is hidden until the extension is already deployed in browsers. That means code review, sandboxing, and marketplace verification can all be bypassed when malicious logic only activates after update or in response to a trigger. User-level install restrictions also fail if a previously approved extension later changes state. This is why the article emphasises that the store may not disable an already installed extension quickly enough to prevent harm.
Practical implication: Monitor for post-installation change, not only for initial installation events.
Why browser extension governance needs lifecycle controls
Extension governance is really lifecycle governance for browser-delivered software. Organisations need to know what is installed, who uses it, how it is deployed, what permissions it holds, and whether its ownership or update history has changed. Without that inventory, teams cannot distinguish a necessary extension from a risky one, and they cannot evaluate whether an update expanded access in ways the original approval did not cover. The control problem is ongoing, not periodic.
Practical implication: Build an inventory and review process that follows each extension through ownership changes, updates, and removal.
Threat narrative
Attacker objective: The attacker wants trusted browser execution that scales through legitimate extension distribution and turns browser access into a broad compromise path.
- Entry occurs when an attacker compromises a legitimate extension path through a phished developer account, a purchased extension, or a benign extension that later turns malicious.
- Credential or control abuse follows when the attacker uses the trusted update channel to publish an obfuscated malicious version that bypasses static analysis and store review.
- Impact occurs when the malicious update runs in employee browsers and steals browser secrets or extends compromise across every installed instance.
Breaches seen in the wild
- GlassWorm campaign 2025: GlassWorm hid in VS Code extensions with invisible Unicode and stole npm, GitHub and Open VSX publishing tokens to spread.
- 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.
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 now function as governed identity-bearing software, not passive add-ons. Once an extension can read browser data, act in-session, and receive updates independently, the old trust model breaks. Approval at install time does not equal safe behaviour at runtime, so browser extension governance has to be treated as a lifecycle discipline. The practitioner conclusion is simple: extension state must be continuously governed, not periodically reviewed.
Static review is an incomplete control when the threat lives in update channels. The article shows that malicious code can hide in plain sight until a later publish, and then the same store mechanisms that delivered trust also deliver compromise. That means store verification, code scanning, and manual approval are all necessary but insufficient when the update path itself is the abuse path. The practitioner conclusion is to control the post-approval state, not just the initial submission.
Browser extension inventory is the missing asset class in many identity programmes. Security teams can only risk-assess what they can see, yet the article shows that enterprise environments may contain hundreds or thousands of extensions if users are free to install them. Ownership history, install count, deployment method, permissions, and update history are the fields that turn an unknown browser surface into a governable one. The practitioner conclusion is to inventory extensions as a first-class part of identity and access control.
Browser extension risk is a browser identity gap. The problem is not only malware, it is the absence of a control plane for browser-resident software that can inherit user trust and act on behalf of the user. That gap sits between IAM, endpoint security, and SaaS governance, which is why it is routinely missed. The practitioner conclusion is to close the browser identity layer with policy, inventory, and monitored change.
Allowlisting changes the governance question from approval to exception handling. Once the default becomes block unless approved, the team can focus on the small set of extensions that actually matter to the business. That is a more sustainable operating model than trying to review every new extension in a sprawling marketplace. The practitioner conclusion is to shift from permissive browsing to controlled extension exposure.
What this signals
Browser identity needs its own control plane. Extension governance sits between SaaS access, endpoint posture, and user behaviour, which is why it is often missed by programmes that only look at login and device controls. Teams should assume that any browser-resident code with update rights can become part of the identity attack surface and plan policy accordingly.
Extension inventory is the practical boundary for risk-based governance. Once organisations can see installation history, ownership, permissions, and deployment method, they can separate business-critical tools from low-value browser sprawl. That visibility is the difference between reacting to a breach and governing the browser estate before it becomes an access path.
For practitioners
- Implement extension allowlisting by default Block unapproved browser extensions and require explicit review before new extensions can run in employee browsers. Use a controlled request workflow so exceptions are managed rather than implied by user choice.
- Build a complete extension inventory Track extension name, ID, version, permissions, deployment method, ownership history, update history, and whether the extension has been unlisted. Use the inventory to identify extensions that should be pruned before they become a risk.
- Monitor extension update and ownership changes Alert on recent updates, publisher changes, new risky permissions, and any detection that indicates a previously approved extension has changed state. Treat those events as governance triggers, not just security alerts.
- Disable browser extension syncing where it increases exposure Stop work-browser sync from carrying extensions across devices when personal profiles or less controlled endpoints are in play. This reduces the chance that a compromise on one device propagates into business browsers.
Key takeaways
- Malicious browser extensions exploit the gap between initial approval and later behavioural change, which makes browser trust a lifecycle issue rather than a point-in-time review.
- The article shows that store checks and static analysis do not reliably stop malicious updates once an extension is already installed in employee browsers.
- A browser extension inventory, strict allowlisting, and ongoing change monitoring are the controls that narrow the browser identity gap.
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 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The article centres on trusted extensions becoming malicious after takeover or republishing. |
| NHI-05 — Overprivileged NHI | Browser extensions often request broad permissions that expand blast radius once compromised. | |
| NHI-07 — Long-Lived Secrets | The article highlights how trusted extensions can remain deployed long after their risk state changes. | |
| Recommendation — Inventory third-party browser extensions and revoke any that change ownership or update behaviour unexpectedly. Limit extension permissions to the minimum needed and remove extensions whose scope exceeds business need. Shorten the approval-to-review window for extensions and revalidate them whenever ownership or code changes. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack path uses trusted browser code to reach secrets and spread across managed browsers. |
| Recommendation — Map malicious extension behavior to credential access and lateral movement tactics in your detections. | ||
Key terms
- Browser Extension Privilege: The access a browser add-on receives through the user’s browser context and granted permissions. In practice, this can include cookies, tabs, page content, and scripting rights, which makes an extension capable of influencing authenticated sessions and web workflows without separate identity controls.
- Browser Identity Attribution: Browser identity attribution is the ability to link a browser-based action to the correct account, tenant, or trust context before data is submitted. In AI governance, it matters because the same user can act through personal or enterprise identities with very different privacy and control outcomes.
- Extension Allowlisting: Extension allowlisting is the policy of permitting only approved plugins or add-ons on developer systems. It reduces exposure by preventing unknown tools from reading source code, collecting tokens, or opening outbound channels without oversight.
- Post-Approval Risk: Post-approval risk is the threat that a software item becomes unsafe after it has already been approved, installed, or trusted. For browser extensions, this often appears when ownership changes, code is updated, or a benign extension is repurposed into a malicious one.
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.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org