Browser Extension Security Risks: What Developers and Security Teams Need to Know
On December 25, 2024, Cyberhaven's security team discovered that its own Chrome extension had been serving malicious code to roughly 400,000 users for more than 24 hours. An attacker phished a Cyberhaven employee with a fake "policy violation" email from the Chrome Web Store, tricked them into authorizing a rogue OAuth app called "Privacy Policy Extension" with publish rights, and pushed a trojanized version 24.10.4 that exfiltrated Facebook Ads Manager session cookies and API tokens. Within days, security researcher John Tuckner traced the same phishing infrastructure to at least 35 other compromised extensions dating back to April 2024, touching an estimated 2.6 million installs. No employee clicked a malicious link inside a browser tab — the extensions auto-updated themselves through the exact channel developers use to ship legitimate fixes. For engineering and security teams, that's the core problem: browser extensions are unmanaged, auto-updating, third-party code running inside the same session as production credentials, SSO tokens, and internal dashboards.
What happened in the Cyberhaven browser extension breach?
On December 24–25, 2024, attackers compromised the Chrome Web Store publishing account behind Cyberhaven's data-loss-prevention extension and shipped a malicious update directly to existing users. The phishing email impersonated Google's Chrome Web Store team and warned of a fake policy violation, linking to an OAuth consent screen for an app requesting permission to manage and publish extensions on the victim's behalf. Once authorized, the attacker used that access to push version 24.10.4, which contained code designed to steal session cookies and OAuth tokens for Facebook Ads Manager, ChatGPT, and other services users had authenticated into through the same browser. Cyberhaven detected anomalous network traffic and pulled the update within about 24 hours, then published a full incident writeup — a level of transparency that let researchers fingerprint the campaign's infrastructure and find the other 35-plus affected extensions, including AI writing tools, VPN clients, and productivity add-ons with a combined install base in the millions.
How do attackers take over browser extensions that are already trusted?
Attackers rarely need to write new malware from scratch — they hijack the publishing credentials of extensions people already trust, then ship the malicious payload through that extension's existing auto-update pipeline. The Cyberhaven campaign used targeted phishing against developer accounts; a different but structurally identical pattern played out with The Great Suspender, a Chrome extension with roughly 2 million users that was sold by its original developer to an anonymous buyer in June 2020. In February 2021, Google removed it from the Chrome Web Store after researchers found the new owner had quietly added tracking and remote-code-execution capability in an update. Both incidents share the same root cause: the browser's trust model treats "signed by the original publisher" as equivalent to "safe," even when the account or the ownership behind that publisher has silently changed hands. Users who installed the extension a year earlier never re-approved anything — the update just arrived.
Why does one permission grant give an extension access to your entire session?
Because the broadest host permission an extension can request — <all_urls>, surfaced to users as "Read and change all your data on all websites" — hands a content script access to every cookie, DOM element, and form field on every site open in that browser, not just the site the extension is nominally built for. A password manager, an ad blocker, and a grammar checker can all request this same permission, and most users grant it without comparing it against what the extension actually needs to function. Multiple audits of enterprise Chrome usage, including Spin.AI's 2023 State of Enterprise Browser Extension Security report, found that a majority of installed extensions request this broadest permission tier, and that the average enterprise employee has around 10 extensions installed at any given time. That means a single compromised or malicious extension doesn't just leak data from one workflow — it sits in a position to read session state for AWS consoles, GitHub, Salesforce, internal admin panels, and email, all inside the same browser profile.
Why do stolen session cookies matter more than stolen passwords?
Because a valid session cookie lets an attacker replay an already-authenticated session and skip login and MFA entirely, turning a browser extension compromise directly into account takeover with no password or one-time code required. This is precisely what the Cyberhaven attackers targeted: rather than credential-stuff a login form, they pulled active Facebook Ads Manager session tokens so they could run or redirect ad spend from compromised business accounts without ever triggering a login alert. Session-cookie theft has become a standard technique across the infostealer ecosystem — malware families like Lumma and RedLine harvest browser cookie stores the same way — and a malicious extension is simply a more targeted, more persistent delivery mechanism for the same outcome, since it runs with the browser's blessing on every page load rather than a one-time smash-and-grab.
Does Manifest V3 actually fix the browser extension supply chain problem?
No — Manifest V3, which Google began enforcing for new Chrome Web Store submissions in mid-2024 and started disabling Manifest V2 extensions for on most user profiles through 2025, restricts remotely hosted code and limits unbounded persistent background pages, but it does nothing to stop an already-approved, legitimately signed extension from shipping a malicious update through its normal auto-update pipeline. That auto-update mechanism is exactly how Cyberhaven's extension and the 35-plus related extensions were compromised: every payload arrived as a routine version bump from a publisher the Chrome Web Store had already vetted and users had already trusted. Manifest V3 raises the bar for extensions that try to smuggle in remote JavaScript at install time; it does not address account takeover, ownership transfer, or insider risk at the publisher level, which is where the highest-impact incidents of the last several years have actually originated.
How can security teams detect and respond to risky extensions before they cause damage?
Security teams need a continuous inventory of every extension installed across the fleet, scored by permission scope and cross-referenced against threat intelligence on known-malicious or recently-compromised publishers, rather than a one-time approval list that never gets revisited. In practice that means treating browser extensions the way you'd treat any other third-party dependency: track what version is deployed, what it can access, whether its publisher account or ownership has changed, and whether a newly pushed update introduces new permissions or network destinations that weren't there yesterday. Chrome Web Store's own catalog holds well over 100,000 extensions, and enterprise device fleets typically accumulate dozens of unique extensions across a workforce with no single owner reviewing new installs — which is why manual spot-checks consistently miss the incident until a researcher or the vendor discloses it publicly, as happened with both Cyberhaven and The Great Suspender.
How Safeguard Helps
Safeguard extends the same software supply chain discipline that catches malicious npm and PyPI packages to the browser extension layer, because an extension is just another third-party code artifact running inside your environment. Griffin AI continuously correlates newly disclosed extension compromises, publisher account takeovers, and IOCs from incidents like the Cyberhaven campaign against your organization's actual installed footprint, so a match surfaces as an alert instead of a headline you read too late. Reachability analysis then determines whether a flagged extension's permission scope actually touches sensitive sessions, cookies, or internal domains in your environment, cutting through permission-list noise to prioritize the handful of extensions that genuinely put credentials at risk. SBOM generation and ingest give security teams a defensible, auditable inventory of every extension version deployed across the fleet, which is the artifact SOC 2 auditors and incident responders both ask for first. Where remediation is code-level — pinning a vulnerable dependency bundled into an internally built extension, for example — Safeguard opens an auto-fix PR so engineering doesn't have to manually track down the fix.