Topic starter
25/10/2026 11:04 am
TL;DR: Trusted Chrome extensions can widen their access after ownership transfers, because the approved artifact may no longer be controlled by the same party, according to Pluto Security. Browser extension inventories need continuous re-vetting, or allowlist decisions can age into unwanted session and permission exposure.
Editorial analysis by NHI Mgmt Group, based on content published by Pluto Security: “Chrome Extension Supply Chain Attacks: How Ownership Transfers Enable Silent Permission Creep”.
Key questions
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.
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.
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.
Practitioner guidance
- Revet allowlisted extensions after ownership changes Require a fresh approval whenever a browser extension changes publisher identity, support contacts, or ownership.
- 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.
Bottom line: Browser extensions can become a supply chain issue after ownership transfer because the approved artifact may no longer be controlled by the same party.
Glossary terms: Silent Permission Creep, Browser Extension Supply Chain Risk, Publisher Identity Drift, Browser Session Theft
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:15 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Chrome extension ownership transfers create hidden supply chain risk
This post was modified 7 days ago by NHI Mgmt Group