Browser Extensions Are the Supply Chain Vector Nobody Audits.

Threat Intelligence

Your engineers run 12 extensions in their work browser. Any one of them, sold or compromised, has DOM access to every SaaS tab they open. The 2025 wave of extension takeovers turned this from theoretical to active.

By Arjun Raghavan, Security & Systems Lead, BIPI · May 8, 2026 · 7 min read

Audit any engineering laptop and you will find 8 to 15 browser extensions installed. Password managers, screenshot tools, JSON formatters, dark mode toggles, ad blockers, AI assistants. Each one is a third-party piece of code with the same DOM access to every SaaS tab the engineer opens: GitHub, Slack, AWS console, Salesforce, the internal admin panel.

The supply chain risk is the same as any npm dependency. The attention paid to it is roughly zero. Throughout 2024 and 2025 we watched a series of compromises and ownership transfers that turned previously-clean extensions into credential-harvesting tools, sometimes weeks before anyone noticed.

How takeovers happen

1. Original developer sells the extension to a buyer who wants the user base. The extension keeps publishing updates from a new owner. Auto-update pushes the new owner's code to every existing user, including yours.
2. Original developer's account gets compromised through phishing. Attacker pushes a malicious update that signs with the legitimate developer key. Chrome / Firefox auto-update.
3. Extension uses a third-party SDK (analytics, A/B testing) and that SDK gets compromised, propagating to every extension that depends on it.
4. Open-source extension is forked into a paid clone with malicious additions, plus an SEO campaign that ranks the clone above the original.

An extension you trusted in January 2024 may not be the same extension running in your browser in May 2026. Auto-update silently replaces the code.

What the malicious extensions do

The pattern is consistent across the campaigns we have analysed: page DOM scraping for cookies, tokens, and form values; specific targeting of SaaS auth flows (Microsoft 365, Google Workspace, Okta, Salesforce, AWS); exfiltration to attacker-controlled domains via the extension's permitted host_permissions; and persistence by installing additional extensions silently or by modifying the user's bookmark / homepage.

Some campaigns are subtler: they exfiltrate only when the page URL matches specific patterns (e.g., /admin/users, /billing/cards), keeping the malicious behaviour invisible during everyday use.

What enterprise IT actually does about this

The defensive options have matured. None are deployed by default. All require active configuration:

• Chrome Enterprise extension allowlists. Only extensions on an explicit list can be installed. New extension requests go through IT review. The default installable set is empty.
• Edge / Chrome Force-Install lists. The reverse: push approved extensions automatically, prevent users from disabling them.
• ExtensionRequest URL: a managed endpoint where users request new extensions, IT reviews permissions, approves or denies.
• Disable extension auto-update for high-risk roles. Updates are reviewed and pushed centrally rather than auto-applied.
• Network egress monitoring for extension-specific traffic. Most malicious extensions exfil to specific domains that show up in DNS logs.

Personal vs work browser separation

The cheap, durable mitigation is browser profile separation. Engineers use one browser profile for work SaaS (with a vetted, minimal extension set) and a different profile (or browser) for personal browsing, where they can install whatever they want. The profiles do not share cookies, sessions, or extensions. This single discipline stops most extension supply chain attacks dead, because the work profile only runs extensions that have passed review.

Some companies enforce this with two physical browsers (Chrome for work, Firefox for everything else). Others use Chrome's profile mechanism with managed policy. The choice depends on operational preference; the principle is the same.

What to do this quarter

1. Inventory: pull the actual extension list from every endpoint via your MDM or EDR. Most teams underestimate how many extensions are running in production by 3-5x.
2. Risk-score each extension: who owns it, when was the last code review, what permissions does it request, where does it exfiltrate (look at the manifest's host_permissions and content_security_policy).
3. Allowlist top 10-15 vetted extensions, block everything else.
4. Add detection: alert on installation of any extension not on the allowlist. Alert on outbound DNS to known extension-malware domains (Recorded Future, Mandiant publish lists).
5. Roll out profile separation policy with engineering. Make 'Chrome work profile' an MDM-deployed thing, not a request.

Closing

Every other supply chain vector has gotten attention: npm, pip, Docker images, GitHub Actions. Browser extensions live in the same threat-model space and get a tiny fraction of the scrutiny. The takeover wave of 2024-2025 should be enough evidence that this is no longer hypothetical. The defensive playbook is mature; what is missing is execution.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.