TL;DR: Koi Security’s ShadyPanda research shows a seven-year malicious browser-extension campaign that infected over 4.3 million users and used about 30 variants to harvest browsing data, persist across devices, and support remote command execution, according to Astrix Security. The case shows that browser extensions, SaaS integrations, and other NHIs need governance, not just human-user controls.
At a glance
What this is: This is a NHI risk analysis showing that malicious browser extensions can operate as unmanaged identities with persistent access, broad data visibility, and remote command capability.
Why it matters: It matters because IAM and security teams often govern the human user while leaving browser-integrated NHIs, extension permissions, and cross-device persistence outside formal control.
By the numbers:
- The campaign used roughly 30 variants of browser extensions to establish a foothold and spread its capability set.
Context
Browser extensions are small pieces of software that run inside the browser, but their permissions often reach far beyond simple productivity tasks. In this case, the security problem is not the browser itself; it is the governance gap around software that can read browsing activity, interact with web applications, and persist outside normal application lifecycle controls.
For identity programmes, browser extensions belong in the same governance conversation as other non-human identities because they carry permissions, depend on trust relationships, and can outlive the moment of installation. When those extensions can be updated, retained, or chained to remote commands without oversight, the control failure is lifecycle blindness rather than user negligence.
Key questions
Q: What breaks when browser extensions are not governed like non-human identities?
A: The main failure is that extensions keep their own permissions, state, and update path while escaping normal identity lifecycle controls. That lets a browser add-on persist after the original user decision, widen its access beyond a single application, and retain cross-device visibility without formal offboarding.
Q: Why do malicious browser extensions create so much risk in modern enterprises?
A: Malicious extensions are risky because they sit inside the browser, where employees do most of their work and where identity, sessions, and data are already in use. Attackers can start with a benign extension, later push a malicious update, or take over an existing extension. That turns a trusted add-on into a delivery path for compromise.
Q: How do security teams decide which browser extensions to allow?
A: Start with a live inventory, then review install count, publisher trust, ownership history, permissions, deployment method, and whether the extension has been unlisted or recently updated. Allow only what is needed for business use, and remove anything that creates more exposure than value.
Q: What should organisations do when a browser extension can persist across devices?
A: They should treat persistence as a lifecycle control problem, not just an endpoint issue. That means tracking where the extension syncs, removing access when it is no longer needed, and making sure residual identifiers or stored state do not survive offboarding.
Technical breakdown
How malicious extensions turn browser trust into identity risk
A browser extension inherits the user’s session context, which means its permissions can effectively act inside the user’s authenticated browser state. Malicious extensions exploit that trust boundary by requesting permissions such as webRequest or browsingData, then using those permissions to observe traffic, manipulate pages, or capture session-linked data. Once installed, the extension becomes a durable execution surface that is much harder to govern than a normal SaaS application because it lives inside the browser and can persist across sessions and devices through browser sync or profile reuse.
Practical implication: inventory extensions with the same seriousness you apply to service accounts and tokens, because browser trust can become persistent identity exposure.
Why cross-device persistence makes browser extensions behave like NHIs
The article’s key risk is not just access, but persistence. A malicious extension that stores a UUID in browser sync can keep tracking a user across devices and sessions, which means the identity signal is no longer tied to one endpoint or one login. That behaviour resembles NHI persistence: a software entity keeps its own state, retains continuity, and continues operating even when the human user logs out or moves systems. In governance terms, this is a lifecycle problem. If the extension is not discovered, approved, and offboarded like other non-human access paths, its privilege survives normal user controls.
Practical implication: treat extension retention and sync behaviour as lifecycle events, not just endpoint hygiene.
How remote command capability changes the governance model
When an extension can function as a remote command execution backdoor, the browser stops being a passive client and becomes an execution environment for attacker instructions. That expands the blast radius from data observation to active manipulation, because the extension can execute actions in the context of a trusted browser session. This is exactly why unmanaged browser software belongs in NHI governance: it can receive instructions, act on them, and retain access independently of the person who installed it. The governance mistake is assuming browser add-ons are low-risk utilities when they can become command-capable identities inside the enterprise stack.
Practical implication: classify command-capable extensions as privileged software entities and subject them to the same approval boundaries as other high-risk NHIs.
Threat narrative
Attacker objective: The attacker objective is long-term surveillance and control of browser-mediated enterprise activity through a persistent extension foothold.
- Entry occurred through apparently useful browser extensions disguised as utilities such as PDF converters or cleaners, which gave the operator a foothold in the browser environment.
- Credentialed browsing context and extension permissions then enabled collection of URLs, navigation patterns, fingerprinting data, and cross-device identifiers while the campaign remained installed.
- The extension’s remote command capability allowed the actor to use malicious command-and-control infrastructure for ongoing execution and spying.
- Impact was sustained enterprise exposure to browsing data, workflow visibility, and persistent tracking across sessions and devices.
Breaches seen in the wild
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
- Google API Keys Exposure — Gemini AI: Google API keys exposed in client-side code via Gemini AI integrations, creating data leak risk.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Unmanaged browser extensions are now an identity governance problem, not a convenience issue. The article shows that extensions can carry permissions, retain state, and operate across devices in ways that resemble non-human identities rather than simple browser add-ons. That means the governance boundary must extend beyond installed software to include who or what can act through the browser. The practitioner conclusion is that browser-integrated software needs identity treatment, not just endpoint awareness.
Browser extension sync creates what we would call identity persistence without lifecycle ownership. The UUID stored in browser sync gives an extension continuity that survives logout, device change, and ordinary user turnover. That persistence is exactly what lifecycle governance is supposed to control for NHIs, yet it often sits outside the access review and offboarding process. The implication is that unmanaged browser software can outlive the accountability model that authorised it.
Privilege in the browser is often wider than privilege in the application. An extension granted access to browsing data or web request flows can observe and influence multiple SaaS systems at once, even when each application individually looks well governed. That creates a hidden identity blast radius because the browser becomes the control plane for many sessions. The practitioner conclusion is that organisations must govern browser-level access paths as part of their identity perimeter.
Policy enforcement must shift from reactive detection to pre-authorisation control. The campaign’s longevity shows that discovery after installation is too late when extensions can persist and command the browser from the inside. The security gap is not only visibility but the absence of enforceable trust criteria for origin, permission scope, and business justification. The implication is that identity programmes should decide what browser-integrated software may exist before it is ever allowed to run.
Browser extensions belong in the same NHI taxonomy as OAuth apps, service accounts, and AI agents. They are software entities that receive permissions, act in a user context, and can retain access independently of human behaviour. That conceptual shift matters because it aligns extension governance with existing NHI lifecycle models instead of treating them as an endpoint exception. The practitioner conclusion is to classify browser extensions explicitly in NHI inventory and lifecycle controls.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: NHI Lifecycle Management Guide
What this signals
Browser-extension identity debt: Every unmanaged extension that can retain state or request browser-wide permissions increases the amount of software acting on behalf of a user without governance. The operational problem is not just malicious code, but the accumulation of browser-integrated identities that are never inventoried, certified, or offboarded. That is where lifecycle discipline becomes a browser-security requirement, not an NHI abstraction.
Access reviews are weak when the subject can disappear into a browser profile and reappear on another device with the same identifier. That means practitioners should shift some control decisions from post-installation review to pre-approval policy, because the review window can be shorter than the persistence window.
Astraix Security? no
For practitioners
- Inventory browser extensions as non-human identities Build a live inventory of installed extensions, their requested permissions, update channels, and browser-sync behaviour across managed endpoints.
- Block high-risk permission combinations Define policy for permissions such as webRequest and browsingData, and require explicit business justification before allowing them.
- Review browser-extension offboarding Remove extensions when the business justification ends, and verify that browser-sync state and residual identifiers are also revoked.
- Classify extensions by blast radius Separate simple utility extensions from command-capable or data-reading extensions so review and approval match actual access scope.
- Enforce origin-based trust controls Use policy to restrict extensions from untrusted origins and require review for suppliers that cannot explain their access path.
Key takeaways
- Malicious browser extensions can function as unmanaged non-human identities when they hold permissions, retain state, and persist across devices.
- The ShadyPanda campaign ran for seven years and affected over 4.3 million users, which shows how long browser-side governance gaps can remain invisible.
- The control that would have reduced this risk is lifecycle governance for extensions, including inventory, permission review, origin trust, and offboarding.
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 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The article centres on third-party browser extensions acting as unmanaged software identities. |
| NHI-05 — Overprivileged NHI | The campaign abused broad browser permissions and access to all resources. | |
| NHI-09 — NHI Reuse | Cross-device sync and persistent identifiers let the same extension state follow users. | |
| Recommendation — Inventory browser extensions as third-party NHIs and block those without clear business justification. Review extension permissions against least-privilege expectations and remove excessive access. Treat synced extension state as reusable identity context and revoke it when offboarding. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Browser extension permissions are entitlements that need explicit governance. |
| Recommendation — Apply PR.AA-05 to approve, review, and revoke extension entitlements on managed browsers. | ||
| CIS Controls v8 | CIS-5 — Account Management | Browser extensions create account-like access paths that need inventory and governance. |
| Recommendation — Use account management controls to inventory extension access paths and remove stale approvals. | ||
| MITRE ATT&CK | TA0006; TA0011 — Credential Access; Command and Control | The campaign harvested data and used remote command infrastructure. |
| Recommendation — Map malicious extension activity to credential access and command and control techniques for detection. | ||
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.
- Cross-Platform Persistence: A method for surviving reboots and logouts across Windows, macOS, and Linux by using platform-native startup mechanisms. Common examples include scheduled tasks, launch agents, and cron entries. In identity and software supply chain incidents, it lets a dropper continue running after the original importing process exits.
- Browser Extension Blast Radius: Browser extension blast radius is the amount of data, identity context, and connected services an extension can reach if it is compromised. It depends on permissions, stored tokens, and linked accounts, not just the extension’s advertised feature set.
- Privileged NHI Inventory: A current record of non-human identities that hold elevated access or can reach high-value systems. This inventory is only useful when it is accurate, owned, and continuously updated, because stale records create a false sense of control and hide the identities most likely to expand attack impact.
Deepen your knowledge
NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org