Cyberhaven Chrome Extension Breach 2024: How One OAuth Consent Hijacked a Security Extension

On Christmas Eve 2024, an attacker published a malicious update of Cyberhaven's Chrome extension to the Chrome Web Store without stealing a single password. A Cyberhaven employee was phished into approving a malicious OAuth application that asked for permission to publish Chrome Web Store extensions. That one consent gave the attacker a publishing identity, and the Web Store pushed the poisoned version to users automatically. Researchers soon found the same technique had been used against dozens of other extension developers, in a campaign that had been running for months.

At a glance

What happened

Cyberhaven sells data loss prevention software, and its Chrome extension is part of that product. On 24 December 2024, an employee with publishing rights for the extension received a phishing email. According to Obsidian Security's analysis, the email reached Cyberhaven's publicly listed support address, and clicking its link sent the employee to a Google authorisation flow for a malicious OAuth application named "Privacy Policy Extension". Cyberhaven told BleepingComputer: "The employee followed the standard flow and inadvertently authorized this malicious third-party application."

The employee had multi-factor authentication and Google Advanced Protection enabled, but BleepingComputer reported that no MFA prompt appeared during the OAuth authorisation. Because the attacker was granted a token rather than a password, MFA never came into play. The token carried permission to "See, edit, update, or publish your Chrome Web Store extensions, themes, apps, and licenses you have access to".

The attacker used that access to upload version 24.10.4 of the extension. Cyberhaven's preliminary timeline, as reported by SecurityOnline, places the attack at about 17:24 UTC on 24 December, with the attacker's exfiltration domain becoming operational at 01:32 UTC on 25 December. Cyberhaven detected the compromise at 23:54 UTC on 25 December, removed the malicious package within 60 minutes of detection, and the exfiltration domain went offline at 02:50 UTC on 26 December. Cyberhaven warned: "For browsers running the compromised plugin, it is possible for sensitive information, including authenticated sessions and cookies, to be exfiltrated to the attacker's domain (cyberhavennext[.]pro)." A clean version, 24.10.5, replaced the malicious one, and according to SOCRadar the company said no other systems, including CI/CD processes or code signing keys, were compromised.

The payload was not aimed at Cyberhaven's own product data. Obsidian Security and BleepingComputer describe two injected files, worker.js and content.js, which contacted a command server and harvested Facebook data: access tokens, user IDs, business and ad account details, cookies and user agent strings. The code also watched mouse clicks on Facebook, apparently to capture QR codes and 2FA or CAPTCHA images.

Within days, researchers linked Cyberhaven to a broader campaign. BleepingComputer reported on 31 December 2024 that at least 35 extensions with about 2.6 million users had been hijacked using the same phishing and OAuth technique, sent from lookalike domains such as supportchromestore.com, forextensions.com and chromeforextension.com. Sekoia, in January 2025, identified 16 compromised extensions and said the operator had been active since at least December 2023, also targeting OpenAI API keys and ChatGPT authentication data. A Booz Allen Hamilton briefing dated 10 January 2025 listed 29 extensions with 2,652,418 users. The counts differ because each firm had different visibility at different times.

Timeline

How it happened: the identity attack path

1. A convincing pretext. Emails from a "Webstore Extension" sender warned that the extension broke Chrome Web Store policy and would be removed, according to Sekoia and Hunters.
2. A real consent screen for a fake app. The link led to Google's genuine OAuth flow. The only malicious element was the application asking for consent, "Privacy Policy Extension".
3. A token instead of a password. Approving the app issued the attacker a token with Chrome Web Store publishing scope. MFA and Advanced Protection protected the login, not the consent, so no second factor was requested.
4. Publishing as the developer. With that token, the attacker uploaded a new extension version. The Chrome Web Store accepted it as a normal update from the legitimate publisher.
5. Automatic distribution. Chrome updates extensions silently, so the malicious code reached users' browsers without any action on their part.
6. Harvesting identities from the browser. The code collected Facebook access tokens, cookies and account details, turning each infected browser into a source of further stolen identities.

Impact

• Cyberhaven users: about 400,000 users of the extension were exposed to version 24.10.4, according to Booz Allen Hamilton.
• Wider campaign: between 16 and at least 35 extensions and about 2.6 million users, depending on the source.
• Data at risk: session cookies, authenticated sessions, Facebook access tokens and business ad account details, plus AI service API keys in some variants reported by Sekoia.
• Trust: a security vendor's own extension became the delivery vehicle, which is what makes browser extension supply chain attacks so damaging.

What this means for NHI governance

The Cyberhaven breach is an OAuth application breach that happened to start with phishing. The person was tricked once, but the attack was carried out by a non-human identity: a third-party OAuth app holding a token with publishing rights. Strong authentication did not help, because consenting to an app is not a login. Many organisations still let any user approve any app for any scope, and few review the tokens those apps hold afterwards.

Store publishing rights are also privileged machine credentials in all but name. Whoever holds a Chrome Web Store, npm, PyPI or VS Code Marketplace publishing token can push code to every user of that product. The same pattern runs through the Salesloft Drift OAuth token breach and the Vercel Context.ai OAuth supply chain breach: an approved app becomes a trusted identity that attackers can steer.

Finally, browsers now hold a large share of an organisation's live identities in the form of session cookies and tokens. An extension with broad permissions can read them all. Extensions deserve the same inventory, ownership and least-privilege review as any other workload.

Recommendations

• Restrict OAuth consent. Limit which users can approve third-party apps, and require admin approval for sensitive scopes such as store publishing, mail and drive access. See our NHI Authentication Guide.
• Review OAuth grants regularly. Inventory the apps holding tokens in your Google Workspace or Microsoft tenant, remove unused ones and alert on new grants with high-risk scopes. Our NHI Lifecycle Management Guide covers ownership and review.
• Protect publishing rights. Keep the set of people and apps able to publish extensions or packages small, use separate accounts for publishing, and require review before a release goes live where the store allows it.
• Train for consent phishing. Staff should know that a genuine Google or Microsoft consent screen can still belong to a malicious app.
• Govern browser extensions. Use an allow-list for enterprise browsers, block extensions with broad host permissions unless approved, and monitor for unexpected updates.
• Revoke and rotate after exposure. If an affected version ran, revoke sessions and rotate tokens and API keys that the browser could reach, as described in our guide to NHI rotation challenges.

Frequently asked questions

How was the Cyberhaven Chrome extension compromised?

A Cyberhaven employee was phished into approving a malicious OAuth application that requested permission to publish Chrome Web Store extensions. The attacker used that access to upload a malicious version, 24.10.4, on 24 December 2024.

Did MFA fail in the Cyberhaven breach?

MFA was not bypassed so much as never involved. The employee had MFA and Google Advanced Protection, but approving an OAuth app issues a token without a new login, so no second factor was requested.

Why is the Cyberhaven breach a non-human identity breach?

The attack was executed by an OAuth application holding a publishing token, and it targeted tokens and cookies in users' browsers. The human was tricked once; the machine identity did the rest.

Related NHI Mgmt Group resources

JetBrains Marketplace AI plugin campaign · Hard-coded secrets in VSCode extensions · Klue OAuth supply chain breach · Top 10 NHI Issues

How NHI Mgmt Group can help

Securing Non-Human Identities (NHIs), including OAuth apps, publishing tokens and AI agents, is becoming increasingly crucial as attackers target the grants and secrets that let software act on our behalf. Our NHI Foundation Level Training Course gives teams the practical grounding to find, govern and protect these identities.

References

• SecurityOnline: Cyberhaven Chrome Extension Compromised in Targeted Attack (December 2024), reporting Cyberhaven's preliminary timeline
• BleepingComputer: New details reveal how hackers hijacked 35 Google Chrome extensions (31 December 2024)
• Obsidian Security: Behind the Breach: Malicious Attack on Cyberhaven's Chrome Extension Developer Team
• Booz Allen Hamilton: Cyberhaven Incident Threat Intelligence Briefing (10 January 2025)
• Sekoia: Targeted supply chain attack against Chrome browser extensions (22 January 2025)
• SOCRadar: Phishing Attack Compromises Cyberhaven's Chrome Extension (30 December 2024, updated 2 January 2025)
• Hunters: Understanding The Chrome Extension Threat Campaign, Beyond Cyberhaven