The Cyberhaven Chrome Extension Attack Explained

By Owen Thurm Published November 6, 2026 5 min read

Quick answer. In December 2024, phishing tricked a Cyberhaven employee into an OAuth grant that let an attacker push a data-stealing Chrome extension update. Cyberhaven caught it within a day; verified uploads and store monitoring target that path.

Watch: The Cyberhaven Chrome Extension Attack Explained 1:42

Video transcript

Over Christmas 2024, a phished OAuth grant let an attacker push a data-stealing update to Cyberhaven's Chrome extension. Publishing rights were enough.

A phishing email posed as Chrome Web Store support. Its link opened a Google sign-in for an OAuth app that could manage extensions. The employee approved, and a malicious update passed review.

Cyberhaven removed it within 60 minutes of detection. Only browsers that auto-updated in a window of about 25 hours received it.

One added file pulled configuration from a command server. Another took data from Facebook ad accounts. A click listener hunted for QR codes, likely to bypass two-factor.

Cyberhaven was one of many. Extension Total tracked 35 extensions hit by the campaign, used by roughly 2.6 million people.

As reported, it targeted ad accounts, not wallets. A year later, a leaked store API key shipped a Trust Wallet build that drained 2,520 addresses, Trust Wallet says.

The employee had MFA, but the OAuth consent never asked for it. Store review cannot judge intent. So require signed uploads, separate the key, audit OAuth grants and watch your listing.

Guardian's Browser Extension Pentest covers six areas: permissions, content scripts, messaging, storage, signing, and supply chain, including who can publish an update.

Read the full article, then talk to Guardian about who can ship your extension, at guardian.security.

Cyberhaven sells data loss prevention software. Its Chrome extension runs in the browsers of its corporate customers.

Over Christmas 2024, that extension became the delivery route for an attack. TechCrunch put its install base at around 400,000 corporate users, citing the Chrome Web Store listing.

Cyberhaven is not a crypto product. But the path the attacker took exists for every wallet extension: whoever can publish to the store can push code to every user who updates.

What Happened

Here is Cyberhaven's own account, as quoted by Security Affairs.

On December 24, phishing compromised an employee's access to the Chrome Web Store.
The attacker published version 24.10.4: a copy of the real extension, plus malicious code.
It passed Chrome Web Store review and replaced the official extension.
Cyberhaven detected it at 11:54 PM UTC on December 25 and removed it within 60 minutes.

Only browsers that auto-updated between 1:32 AM UTC on December 25 and 2:50 AM UTC on December 26 got it, Security Affairs reported. That is a window of about 25 hours.

A clean version, 24.10.5, followed on December 26. Users were told to update, revoke passwords that are not FIDOv2, rotate API tokens and review browser logs, BleepingComputer reported.

Cyberhaven said no other systems, "including our CI/CD processes and code signing keys," were compromised. It hired Mandiant and said it was cooperating with federal law enforcement, according to TechCrunch.

How the Attack Worked

The attacker did not need Cyberhaven's code or build systems. Publishing rights were enough.

The phishing email

The email posed as Chrome Web Store developer support. It claimed the extension's description broke policy and that the extension would be removed.

Its link opened a real Google sign-in flow for an OAuth app called "Privacy Policy Extension." The app asked for permission to manage the victim's Chrome Web Store extensions.

The employee approved it. Cyberhaven said he had MFA and Google Advanced Protection enabled, got no MFA prompt, and his Google credentials were never stolen.

The malicious update

The attacker added two files to a copy of the real extension, BleepingComputer reported: worker.js and content.js.

worker.js contacted a hardcoded command server and downloaded its configuration.
The Hacker News named the command domain as cyberhavenext[.]pro.
content.js collected data from targeted sites and sent it to the attacker.
The target was Facebook ad accounts: access tokens, user IDs, ad and business accounts.
A click listener on facebook.com looked for QR code images, likely to get past 2FA.

Cyberhaven's email to customers said the code could exfiltrate "authenticated sessions and cookies," per TechCrunch.

Cyberhaven said its early analysis pointed to a non-targeted attack, part of a wider campaign aimed at Facebook Ads users.

Timeline and Impact

Date (UTC)	Event	Source
Dec 24, 2024	Phishing gives the attacker store access	Cyberhaven
Dec 25, 1:32 AM	Auto-updating browsers start receiving 24.10.4	Security Affairs
Dec 25, 11:54 PM	Detected; package removed within 60 minutes	Cyberhaven
Dec 26, 2:50 AM	Affected update window closes	Security Affairs
Dec 26	Clean version 24.10.5 published	BleepingComputer
Dec 27	Cyberhaven's CEO posts its account	TechTarget

The 400,000 figure is the listing's user count, not the number affected. Only browsers that auto-updated inside the window got the bad version.

Cyberhaven said it reached "a portion of our customer base." It declined to tell TechCrunch how many affected customers it notified.

Cyberhaven was one of many. Extension Total tracked 35 extensions hit by the same campaign, used by roughly 2.6 million people, BleepingComputer reported.

Secure Annex's John Tuckner told The Hacker News the campaign may have run since April 2023.

As reported, the payload went after Facebook advertising accounts, not wallets.

What It Shows for Wallet Extensions

Swap the payload and the same path reaches a wallet. Three lessons carry over.

The store account is a key

Whoever can publish an update can run code in every browser that installs it. In a wallet, that code runs beside the keys while the wallet is unlocked.

A year later, a leaked store API key shipped a Trust Wallet build that drained 2,520 addresses, Trust Wallet says. See the Trust Wallet extension hack explained.

MFA did not cover the OAuth grant

The employee had strong MFA. The consent screen asked for no second factor, and it handed over publishing rights.

Store review is not your release gate

The malicious version passed "the customary Chrome Web Store Security review process," Cyberhaven said. Review cannot tell whether you meant to ship it.

Fake wallets have used review the same way. See GreedyBear's 150 fake wallet extensions.

Controls that target this path

Opt in to verified CRX uploads, so every update must be signed with your key.
Keep that signing key away from the accounts and CI that hold store access.
Audit which OAuth apps can act on publisher accounts, and revoke unknown grants.
Check any store policy warning in the developer dashboard, not through an email link.
Watch the listing for versions you did not ship, and diff each against source.

Chrome says verified uploads "can prevent malicious updates if your developer account is compromised." Our browser extension pentest guide covers the rest of the pipeline.

How Guardian Tests This Surface

Guardian's Browser Extension Pentest tests what a hostile site can extract and what a bad update could do. It covers six areas:

Permissions and manifest: how far a malicious version could go.
Content scripts: what a hostile site can reach through them.
Internal messaging: whether a page can hit a privileged handler.
Key and session storage: what is readable while unlocked.
Signing flows: whether what gets signed matches what the user approved.
Supply chain: bundled dependencies, build integrity, and who can publish a store update.

That last area is the Cyberhaven path. Source code is effectively required, since a store download cannot confirm every path was reviewed.

For the accounts and pipelines behind a release, Guardian's infrastructure pentest covers IAM, secrets and CI/CD.

Frequently Asked Questions

How was the Cyberhaven Chrome extension compromised?

A phishing email posing as Chrome Web Store support led an employee to authorize a malicious OAuth app called Privacy Policy Extension. The attacker used that access to publish version 24.10.4: the real extension plus data-stealing code.

Did MFA stop the Cyberhaven attack?

No. Cyberhaven said the employee had MFA and Google Advanced Protection enabled and received no MFA prompt. The attacker never needed the password: the OAuth grant itself carried permission to manage the store listing.

Were crypto wallets affected by the Cyberhaven attack?

As reported, the payload targeted Facebook advertising accounts, not wallets. The same route, publishing access taken from the developer, was used against Trust Wallet's extension in December 2025.

How can an extension team stop a malicious store update?

Opt in to Chrome's verified CRX uploads, which require every update to be signed with your key, and keep that key away from store credentials. Then watch the listing for any version you did not ship.

Sources

Test who can ship your extension

Guardian tests your extension against hostile websites and bad updates, from the manifest and key storage to who can publish to the store.

Talk to Guardian Explore the Browser Extension Pentest