Browser extension risk scores miss the compromises that matter

At a glance

What this is: This analysis argues that browser extension risk scores rarely predict real compromise, because the extensions that breach environments usually appeared benign until they were weaponized.

Why it matters: IAM and security teams need to treat browser extensions as controlled software with privileged access, not as reputation-scored add-ons, or they will miss the changes that actually precede compromise.

👉 Read Push Security's analysis of why browser extension risk scores miss real compromise

Context

Browser extensions sit inside the trust boundary of the browser itself, which means they can read page content, interact with sessions, and touch the same workflows as the user. That makes them a browser identity and access problem as much as a software supply chain problem.

The failure in most scoring models is structural: they describe an extension's current reputation, not whether it can be turned into a compromise on the next update. For IAM and security teams, the question is not which extensions look risky today, but which approved extensions can become high impact tomorrow.

Extension governance should therefore be treated as a controlled population problem. The practical unit of management is the approved extension set, plus the changes that indicate ownership transfer, permission escalation, or malicious update behavior.

Key questions

Q: How should security teams govern browser extensions in enterprise environments?

A: Security teams should govern browser extensions with default deny, a strict allowlist, and continuous monitoring of the approved set. The goal is not to score every extension, but to prevent unapproved software from running and to detect meaningful lifecycle changes such as ownership transfer, permission escalation, or malicious update behavior. Treat extensions as privileged software, not optional add-ons.

Q: Why do browser extension risk scores miss the compromises that matter?

A: They miss the compromises that matter because they measure static reputation rather than future weaponization. A clean install count or good rating does not predict whether a trusted extension will be compromised, sold, or updated with malicious code later. The real risk is change over time, so governance must watch for events, not just attributes.

Q: What breaks when organisations rely on install count and ratings for extension trust?

A: Trust breaks because popularity can be manufactured and then preserved until the moment of compromise. High install count often appears in attacks after the extension has already gained a user base, and ratings can be inflated by bots. That makes reputation data useful for description, but weak for decision-making.

Q: When should teams block a browser extension rather than review it further?

A: Teams should block an extension when it changes ownership, receives a suspicious permission increase, starts loading remote payloads, or is linked to known malicious activity. Those are not minor hygiene issues. They are indicators that the extension has moved from approved software to active compromise risk, and they warrant containment before continued use.

Technical breakdown

Why browser extension permissions are a privilege problem

Permissions determine what an extension can do if it turns malicious. Broad host access, scripting, and cookie access can enable session theft, token capture, and page manipulation across the browser. The problem is that these permissions are common in legitimate tools, so static scoring ends up describing capability rather than compromise likelihood. That is why a high permission score does not separate a password manager from a malicious extension in a meaningful way. The technical issue is not just reach, but the browser's built-in trust in extensions once those permissions are granted.

Practical implication: inventory extension permissions as a privilege model, not as a reputation signal.

Why install counts and developer reputation fail as controls

Install count, ratings, badges, and developer reputation are all point-in-time trust signals. Attackers can wait until an extension has enough users, compromise a legitimate developer account, or buy an extension after it has built trust. That creates a sleeper-agent pattern in which the extension is clean until the moment it is not. These signals do not predict future ownership changes or post-install malicious updates, which is why they consistently miss the compromise path seen in supply chain attacks.

Practical implication: monitor for ownership change and developer account change instead of relying on popularity or badges.

How malicious updates evade static code review

Static analysis can only inspect what is present at review time, while extension attackers increasingly hide malicious behavior behind delayed activation, remote payload loading, and conditional execution. If a payload is fetched later, or only activates for a subset of users, review tooling may never observe the harmful branch. This is why a clean review does not mean a clean lifecycle. The attack surface is the update channel, not just the submitted code bundle.

Practical implication: treat update-time behavior changes as the primary detection surface, not initial submission review.

Threat narrative

Attacker objective: The attacker aims to weaponize trusted browser software so it can steal sessions, exfiltrate data, and convert browser access into account compromise at scale.

1. Entry occurs when a legitimate browser extension is compromised through developer account takeover, ownership transfer, or a malicious update channel.
2. Credential access follows when the extension uses granted browser permissions to read cookies, session tokens, or page data from active user sessions.
3. Impact occurs when the compromised extension exfiltrates data, hijacks accounts, or pivots into broader application access across the browser estate.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser extension risk scoring is a backward-looking description of trust, not a forward-looking control. Permissions, install counts, ratings, and developer reputation all describe the extension as it appears at evaluation time. The extensions behind major breaches were often normal or low-risk before compromise, which means the score was accurate about the past and useless about the attack path. Practitioners should stop treating the score as a decision maker and start treating it as a weak label on a moving target.

Ownership transfer is the named concept this category should be built around. An extension that changes hands can preserve every reputation signal while becoming a different security object entirely. That is why ownership transfer, developer contact change, and update-time permission escalation matter more than install popularity. The implication is that extension governance should be event-driven, not static.

The real control boundary is the approved extension set, not the risk-ranked extension set. Default-deny is the only model that reliably reduces exposure because it collapses the population to tools with a declared business purpose. Once that baseline exists, the meaningful question becomes which approved tools changed in ways that indicate weaponization. Practitioners should govern the allowlist as a living asset.

Static analysis cannot solve a supply chain problem that is timed to outlast review. Delayed activation, remote payloads, and conditional execution are designed to produce a benign review artifact while preserving malicious runtime behavior. That creates a governance gap between code inspection and live behavior. Security teams should assume that review infrastructure can validate submission quality, not trustworthiness over time.

Browser extensions belong in the same governance class as other privileged software dependencies. They can read sessions, modify content, and affect core business applications, so they deserve lifecycle monitoring, control exceptions, and change detection. The field should stop framing extension management as a niche browser issue and treat it as an identity-adjacent access problem with supply chain characteristics. Practitioners should manage them accordingly.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
• For broader NHI lifecycle and breach context, see The 52 NHI breaches Report for case patterns and root cause analysis.

What this signals

Ownership transfer is the new governance signal. Browser extensions can look trustworthy at install time and become high-risk later, which means identity and endpoint teams need controls that watch change events instead of reputation snapshots. That shift aligns extension governance with the broader NHI pattern of monitoring lifecycle movement, not just initial approval.

The browser is becoming a privileged execution layer for third-party code, and that creates a control requirement that traditional app allowlisting never had to address at this granularity. Teams should expect more pressure to correlate extension metadata with session risk, application access, and user privilege rather than treating the browser as a passive client.

With two-thirds of enterprises already reporting a successful attack from compromised non-human identities, the operational lesson is clear: static trust scoring is not a substitute for lifecycle governance. Extension management is part of the same control family as service account oversight, only the runtime surface is the browser.

For practitioners

• Build a strict extension allowlist Inventory every browser extension in use, classify how it was installed, and block everything not tied to a legitimate work purpose. Use a default-deny model so new or unapproved extensions cannot execute without explicit approval.
• Monitor approved extensions for lifecycle changes Alert on ownership transfers, developer contact changes, permission escalations, and delisting events. These are the changes that precede real-world weaponization and should trigger investigation before the next user session completes.
• Treat extension updates as security events Require review when a trusted extension introduces new permissions, remote code loading, or delayed activation behavior. Update-time change, not store reputation, is the operational signal that matters.
• Feed extension telemetry into SIEM and SOAR Route extension metadata changes into detection workflows so one ownership change can combine with version and permission changes to trigger block actions automatically. The point is to act on meaningful change, not recalculate a score.

Key takeaways

• Browser extension breaches are usually won by lifecycle change, not by obviously dangerous code at install time.
• Reputation scores are weak predictors because attackers can wait, compromise, or transfer trusted extensions before weaponizing them.
• The practical control is a strict allowlist with monitoring for ownership transfer, permission changes, and malicious update behavior.

Key terms

• Browser Extension Allowlist: A browser extension allowlist is the approved set of extensions that are allowed to run in an organisation. It replaces broad trust with explicit approval, so every other extension is blocked by default and only tools with a declared business purpose are permitted.
• Ownership Transfer: Ownership transfer is the point at which an extension changes hands, either through sale, account compromise, or developer handoff. It matters because the extension can keep the same name, rating, and install base while becoming a materially different security object after the transfer.
• Sleeper Agent Strategy: A sleeper agent strategy is when an extension or software dependency remains benign until it has accumulated trust, users, or access, and only then is weaponized. In browser security, this defeats reputation scores because the dangerous change happens after the initial trust decision.
• Runtime Weaponization: Runtime weaponization is the shift from a clean-looking extension to one that performs malicious actions only after it is installed and trusted. It often relies on delayed activation, remote payloads, or conditional execution, which makes static review a weak predictor of live behavior.

Deepen your knowledge

Browser extension governance and allowlisting are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment already treats browser add-ons as privileged software, the course helps formalise that control model.

This post draws on content published by Push Security: Why typical browser extension risk scores are poor predictors of compromise. Read the original.