TL;DR: Trusted Chrome extensions can turn into enterprise blind spots after ownership transfers, because publisher identity can change while the extension ID, allowlist status, and user trust remain intact, according to Pluto Security research. The control gap is continuous re-vetting, not one-time approval.
At a glance
What this is: Pluto Security examines how browser extension ownership transfers can create a silent supply chain risk when trusted extensions keep their IDs but change hands, permissions, and intent.
Why it matters: This matters because browser extensions often sit outside normal IAM and endpoint controls, yet they can access sessions, form data, and corporate web activity once their permissions expand.
Context
Browser extensions are a governed access surface, not just a convenience layer. Once an extension is allowed into the enterprise, its publisher, permissions, update cadence, and runtime behaviour all become part of the security decision.
This article is about a familiar governance failure: organisations treat extension approval as a one-time event, even though ownership, code, and scope can change after deployment. That makes browser extensions a persistent supply chain risk rather than a static software inventory problem.
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 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: How can security teams detect browser extension privilege drift?
A: Teams should baseline extension permissions at approval time and then compare those permissions after each update. Any new access to cookies, scripting, browsing history, or tab control should trigger re-review. If the extension can expand silently, the governance process is already behind the risk.
Q: Should organisations block all browser extensions or inspect them more deeply?
A: Blocking everything is usually unrealistic, but shallow trust is equally unsafe. The practical middle ground is to allow only approved extensions, then inspect runtime behaviour on the browser-to-host path. If an extension can touch downloads, it deserves the same scrutiny you would apply to code that can influence endpoint execution.
Technical breakdown
How extension ownership transfers become an attack surface
A browser extension can stay technically identical while its controlling entity changes, which is why ownership transfer matters. The extension ID may remain stable, but the new owner can alter code, permissions, support channels, and update cadence without changing the trust decision already made by IT. That creates a governance blind spot: the approval was tied to the artifact, not the publisher relationship. In practice, enterprises inherit whatever intent the new owner brings after the transfer, including data collection or credential theft. See the Browser Extension Security Guide.
Practical implication: Treat publisher identity as part of the security boundary, not just the extension ID.
Why permission creep in Chrome extensions is hard to see
Chrome extensions request capabilities through a manifest, and later updates can expand access in ways that look routine to end users. The risk is not only obvious prompt-based consent changes. Broad host access, new API use, background script changes, and CSP loosening can materially change what the extension can observe or inject. If monitoring only tracks whether the extension is still installed, the real security change is missed. The control gap is version-aware authorization, not installation state.
Practical implication: Compare each new extension version against the permissions and scripts that were originally approved.
What malicious extensions can do after gaining broader access
Once an extension has expanded permissions, its abuse patterns resemble lightweight browser-side malware. It can hijack sessions by stealing cookies, harvest credentials from web forms, inject content into legitimate websites, and exfiltrate internal URLs or browser history to external infrastructure. Those behaviours are especially dangerous because the browser is already trusted by users and often by security tooling. The attacker does not need to break the endpoint first; they can exploit the browser’s own trust chain.
Practical implication: Monitor browser telemetry for session abuse and unexpected outbound connections from high-trust extensions.
Threat narrative
Attacker objective: The attacker wants to turn a trusted browser extension into a covert collection and session-hijacking channel inside managed enterprise browsers.
- Entry occurs when an attacker acquires a trusted extension and inherits its installed base without disrupting normal use.
- Credential access begins after the extension receives broader permissions and can capture session cookies or credentials entered into web forms.
- Exfiltration follows when the malicious extension sends internal URLs, form data, or browsing history to external infrastructure.
- Impact is the loss of browser trust, session integrity, and potentially downstream access to corporate applications and data.
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.
- Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.
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 extension governance has become a lifecycle problem, not an approval problem. Once an extension is allowlisted, most organisations stop reassessing the trust relationship, even though the publisher, code, and intent can all change later. That is a poor fit for modern extension markets, where acquisitions and ownership transfers are normal. Practitioners should treat extension trust as an ongoing control surface, not a one-time procurement decision.
Publisher identity drift is the core control gap here. Enterprises often key policy to the extension ID while ignoring who controls that ID today. That leaves a gap between artifact continuity and governance continuity, which is exactly where hostile ownership transfer thrives. OAuth app governance offers the right mental model here: the thing that was trusted yesterday can be controlled by a different party today.
Silent permission creep is the named concept security teams should now track. The extension may still look legitimate while its access profile expands through host permissions, API additions, and background script changes. That creates a hidden privilege increase that normal allowlist checks will not catch. The practical conclusion is that browser access must be continuously re-authorised whenever the permission surface changes.
Browser extensions now belong in the same governance conversation as third-party integrations and NHI-like access paths. They are not NHIs in the strict sense, but they behave like delegated software identities with durable access to sessions, data, and corporate workflows. Once that is acknowledged, the right questions become ownership, scope, and revocation, not just installation hygiene.
For identity teams, the lesson is that trust materialises in runtime behaviour, not in the approval record. A clean approval process does not protect against later code changes, support URL changes, or sudden shifts in review patterns. Security operations should watch for those signals as evidence that the trust relationship itself has changed, and act before the extension becomes a browser-side exfiltration path.
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
Silent permission creep: the real risk is not that a browser extension exists, but that its access profile can expand after approval without a fresh governance event. Security programmes should treat ownership transfer, manifest drift, and new API usage as triggers for re-authorisation, not just as software maintenance.
Browser extension monitoring should now sit alongside SaaS app governance and session-risk controls. The same governance logic that applies to delegated access, consent scopes, and revocation should apply when a browser add-on can read pages, inject scripts, or touch authenticated sessions.
The most defensible control is a runtime trust model: continuous review of who controls the extension, what it can access, and whether its behaviour still matches the original approval.
For practitioners
- Revet allowlisted extensions after ownership changes Require a fresh approval whenever a browser extension changes publisher identity, support contacts, or ownership. Treat the transfer itself as a governance event, not just the code update.
- Track manifest and permission deltas Compare each new version against the last approved manifest, with special attention to new host permissions, tabs, cookies, webRequest, nativeMessaging, and CSP relaxation.
- Enable extension inventory and reporting Use browser management telemetry to inventory installed extensions, versions, and permission scopes across managed devices so changes are visible before users notice them.
- Investigate update spikes and network anomalies Review sudden bursts of extension updates, new outbound destinations, and suspicious review-pattern changes as indicators of post-transfer activity.
- Build a suspend-first response playbook When a suspect extension changes hands or scope, disable it through policy first, preserve forensic evidence, and only then remove it from the fleet.
Key takeaways
- Browser extensions can become a supply chain issue after ownership transfer because the approved artifact may no longer be controlled by the same party.
- The dangerous part is not just installation, but silent expansion of permissions and browser-session access after approval.
- Continuous re-vetting, inventory, and policy-based suspension are the controls that reduce this risk most directly.
Related NHI Mgmt Group resources: Browser Extension Security Guide · CI/CD Pipeline Identity Security Guide · SaaS-to-SaaS and OAuth App Governance Guide · Software Supply Chain Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Extension permission drift and manifest changes create a misconfiguration-style trust failure. |
| Recommendation — Track extension manifest drift as a configuration risk and revoke access when scope expands unexpectedly. | ||
| CIS Controls v8 | CIS-5 — Account Management | Browser extensions act like delegated accounts whose lifecycle must be managed and revoked. |
| Recommendation — Inventory and review delegated browser access paths with the same discipline used for account lifecycle control. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on whether extension permissions still match the approved entitlement. |
| Recommendation — Revalidate browser extension entitlements whenever ownership, permissions, or update behaviour changes. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack path relies on stealing sessions or credentials and sending data out covertly. |
| Recommendation — Map suspicious extension behaviour to credential access and exfiltration techniques in detection workflows. | ||
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.
- Publisher Identity Drift: A change in who controls a software or extension publisher after the product has already been approved for use. In practice, the ID may stay the same while the operating intent changes, which makes static allowlists and approval records unreliable unless they are continuously revalidated.
- Silent Permission Creep: A gradual expansion of an extension’s access rights through updates that do not obviously alarm users or administrators. The danger is that a tool can move from narrow, legitimate behaviour to broad browser access, creating a larger attack surface without a fresh governance decision.
- Browser Session Theft: Browser session theft is the capture of authenticated web-session state after a user has already signed in. It is dangerous because the attacker may not need to know the password or defeat MFA again, only reuse the live session to act as the victim.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programme they already run.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org