Browser Extension Supply Chain Attacks: Trusted Update, Hostile Code

Most supply-chain writing focuses on build systems and package registries. The browser is the quieter version of the same problem, and for cloud teams it is arguably worse: the browser is where your console sessions, SSO cookies, and SaaS admin tokens live, and an extension sits inside that trust boundary with permissions you granted once and never revisited. In late December 2024, Cyberhaven, a data-security vendor, disclosed that its own Chrome extension had been hijacked and pushed as a malicious update (Cyberhaven). Researchers then linked it to a wider campaign against many other extensions. It is the cleanest case study of the pattern, so that is what this post dissects.

What happened

The attack started with a phishing email to the extension developer, posing as a Chrome Web Store policy notice and warning that the extension risked removal. The link led to a legitimate-looking OAuth consent screen for a malicious third-party app. The developer granted it access to their Google account’s Chrome Web Store publishing permissions. Notably, no password was stolen and the MFA prompt never fired: the attacker held a valid OAuth grant, so credential-based defenses had nothing to catch.

With that grant, the attacker uploaded a trojanized build and the Web Store published it. Chrome’s auto-update did the rest, delivering the modified extension to users without a single click. Per Cyberhaven’s disclosure, the malicious code contacted an attacker-controlled domain for configuration and harvested data from authenticated sessions, with a focus on Facebook advertising accounts. The compromised version was live for roughly a day before it was detected and pulled.

Root cause

Three things lined up, and none of them is a browser vulnerability:

• Publishing identity was a single Google account. Whoever controls that identity (or holds an OAuth grant to it) controls what ships to every user.
• OAuth consent phishing bypasses MFA. The user authenticates legitimately and simply approves the wrong app. Token-based access persists after the page is closed.
• Silent auto-update is the distribution channel. It is a feature for patching and, for the same reason, an ideal delivery mechanism for an attacker. Users and admins never see a review step.

Blast radius

The victim list of a hijacked extension is everyone who has it installed, and enterprise-managed extensions are the worst case: force-installed by policy, present on every managed browser, and often granted broad host permissions (<all_urls>) so they can “see” whatever the product monitors. That access is the payload. Session cookies and bearer tokens for your AWS console, your IdP, GitHub, and your ticketing system are reachable by any extension that can read page content or use the cookies API. Stolen sessions skip MFA entirely, the same failure mode covered in the Citrix Bleed analysis.

Remediation

Control what installs. Use Chrome Enterprise (or Edge/Firefox policy) to run extensions on an allowlist. Block everything else with ExtensionInstallBlocklist: ["*"] and explicitly permit approved IDs via ExtensionInstallAllowlist. Extension IDs are stable, so this is cheap to maintain and stops the long tail of shady tools.

Review permissions, not just names. For each approved extension, record what it can touch. Anything requesting all-site access, cookies, webRequest, or debugger deserves the same scrutiny as a third-party SaaS integration. Chrome’s ExtensionSettings policy can restrict host access to specific sites (runtime_blocked_hosts), so a helper tool never sees your cloud console at all.

Pin or delay updates for high-risk extensions. Where you can, stage rollouts: a pilot group gets updates first, everyone else follows after a soak period. The Cyberhaven version was live for about a day, so even a short delay would have spared many organizations.

Harden the identity that publishes. If you ship an extension, put its publishing account behind phishing-resistant MFA, restrict who can approve OAuth apps on the Workspace domain, and use a group-owned publisher account rather than a personal one. Google Workspace admins can block unverified third-party apps from requesting sensitive scopes.

Shorten the value of stolen sessions. Set short session lifetimes on the IdP and AWS IAM Identity Center, bind sessions to device posture where supported, and alert on impossible-travel or new-device token use. A stolen cookie is far less useful if it expires in hours and only works from managed hardware.

Watch for the tell. New outbound requests from browsers to unfamiliar domains right after an extension version bump are the signal. DNS or proxy logs correlated with extension update events give you a cheap detection.

Takeaway

The browser extension store is a software distribution channel with a one-account trust anchor, and your users’ most sensitive sessions sit behind it. Treat extensions like any other third-party dependency: inventory them, allowlist them, scope their permissions, and stage their updates. The attacker in this case never touched a password, so the controls that matter sit around consent and distribution, not login.