Browser threats

In 2025 alone, adversaries used malicious browser extensions to steal active session cookies and cryptocurrency, spy on users browsing activities, hijack users’ browsers, and even remotely execute code on victims’ machines. Millions of users were directly impacted by the breadth of malicious Chrome extensions uploaded to the Chrome Web Store in 2025.

The pervasive and severe nature of these attacks underscores the urgency for action. Therefore, security professionals must immediately and proactively take definitive control of browser and extension management. This critical step is absolutely essential to safeguard users and protect the organization’s sensitive data living within the browser.

Malicious browser extensions in 2025

The threat of malicious browser extensions is not new, with reports dating back to the early 2010s. However, 2025 saw a noticeable surge in malicious extensions uploaded to browser marketplaces. Adversaries exploited a perfect storm of vulnerabilities: misplaced user trust in the marketplaces, weak organizational oversight, relaxed extension review processes, and the ease of acquisition—either directly or through sophisticated supply chain attacks compromising reputable ones. These methods allowed adversaries to silently install malware on millions of user devices.

The browser extension ecosystem is an attractive target for several distinct reasons:

• Users implicitly trust their browser and its built-in extension marketplace.
• An extension is fundamentally manipulable code that adversaries can use to exfiltrate cookies, dynamically change functionality via remote code execution, or hijack users’ searches.
• The security review for updating extensions already in the marketplace is frequently less stringent than for initial submission.
• The default auto-updating mechanism of most browsers ensures extensions stay current without user interaction, allowing adversaries to rapidly deploy malicious code to a massive user base.
• Organizations typically lack effective processes for managing, reviewing, approving, or tracking extensions.
• Traditional endpoint monitoring tools fundamentally lack visibility into extension activity within the browser.
• Since monetizing extensions is often difficult, legitimate developers can be tempted to silently sell and transfer ownership to interested, and often malicious, buyers.

Precursor: The Cyberhaven supply chain attack

The scale of this threat was chillingly foreshadowed in December 2024 by a supply chain attack targeting Chrome extension developers. This campaign led to the compromise of 35 Chrome extensions, ultimately impacting over 2.6 million users, with the Cyberhaven extension being a notable casualty.

The attack began with a deceptive email leading developers to a legitimate Google login page, which then fraudulently requested authorization for a malicious Google OAuth application named “Privacy Policy Extension.” Crucially, this application sought the https://www.googleapis.com/auth/chromewebstore scope. Once the adversary-controlled app was granted permissions, the attacker was able to publish a malicious version of Cyberhaven’s extension, version 24.10.4, to the Chrome Web Store.

Primer: Anatomy of a browser extension

As a quick primer, a browser extension is typically composed of HTML, CSS, and JavaScript, and the package of a browser extension contains a manifest file in its root directory that lists important information about the structure and behavior of the extension.

 Below is an example manifest, which can be read as such:

Version 1.0.0 of the “Test” extension, has the cookies and management permissions, which allow it to query or modify cookies, and manage installed apps and extensions. The extension is granted these abilities across all websites due to the <all_urls> host permission. The extension also uses a content script named content.js, which is able to read details of any web pages the browser visits, make changes to them, and pass information to their parent extension, again enabled by the <all_urls> matching criteria. Finally, a service worker named background.js serves as the extension’s main event handler, which facilitates communication between the content.js and background.js scripts across process boundaries.

The adversary behind the Cyberhaven incident added a new content script to the extension: content.js. This script was configured to run as soon as the page loads (“run_at”: “document_start”) and its primary purpose was to exfiltrate users’ Facebook session cookies and authentication tokens, sending that information to the adversary’s command and control server.

This event set the stage for the year ahead, as reports of dangerous extensions surged to more than 200 throughout 2025, according to this Spin.AI tracker.

The year concluded with two eye-opening incidents that serve as critical warnings.

Phantom Shuttle

One incident involved two extensions, both named Phantom Shuttle, available in the Chrome Web Store (one since 2017, the other since 2023). On December 22, 2025, security researchers publicly disclosed a malicious version update (version 3.1.9, released December 15, 2025). While originally masquerading as VPNs, deeper code analysis revealed the extensions’ true intent: secretly stealing credentials from over 170 platforms. The targeted platforms would create a lateral-movement nightmare for any modern organization.

Prominent targets included developer tools (GitHub, Stack Overflow, Docker, npm), cloud services (AWS, Digital Ocean, Azure), corporate platforms (Cisco, VMware), and social media/adult content sites—the latter potentially being used for blackmail.

Trust Wallet

A second major incident was a supply chain attack in December, targeting the Trust Wallet Chrome extension and resulting in the theft of an estimated $7 million USD in cryptocurrency.

These cases demonstrate that seemingly benign or legitimate browser extensions can be weaponized with startling speed and capability. This proves that Chrome extensions pose a significant, active risk to organizations rather than a merely passive one.

Fortunately, the common browsers found in an enterprise are Google Chrome, Microsoft Edge, and Mozilla Firefox, all of which can be managed across Windows, Linux, and macOS devices using tools like Group Policy, MDM solutions (e.g., Jamf), or the Google Admin console. This centralized management offers opportunities to mitigate the threat of malicious browser extensions, which primarily relies on two factors: users being able to install extensions at will and extensions auto-updating with new, unreviewed code.

Prevention and mitigation

To prevent users from introducing unvetted browser extensions and to control the auto-updating of sanctioned extensions, there are three primary mitigation options.

Only allow managed browsers

This option enforces that users only utilize browsers that are managed. This prevents the installation and use of unmanaged browsers, ensuring that organizational policies designed for protection cannot be easily circumvented.

Allowlist

This option restricts users from installing any browser extensions not on the organization’s allowlist. This requires users to request an extension be added, allowing administrators to vet the extension before it’s used in the environment. This method offers the highest level of security without completely blocking extensions for users, ensuring they still have a path forward for tools that offer real utility, without overt or hidden malicious intent.

Version pinning

This option is a bit of a double-edged sword. Ideally, you’d want to ensure extensions stay up to date across the enterprise to receive new features and, most importantly, security patches. However, when an extension is updated with net-new unvetted code, there is potential for that code to be malicious, either because an adversary compromised the extension developer’s account or the developer themselves turned the extension malicious.

Pinning the versions of the extensions in your environment allows administrators to re-vet the extension’s code and ensure that requested permissions and scripts have not changed in a way that introduces undesired security and privacy risks.

Response/remediation

If a malicious or risky browser extension is detected in your environment, use its ID to uninstall and block it through your management options. The extension should only be re-added to the allowlist if there is a persistent business requirement, and only after the extension authors have both provided a public statement explaining the compromise and released an update that eliminates the malicious code. Following such, consider also pinning the extension version.

If the browser is unmanaged and a malicious extension was discovered via threat hunting, your response team should direct all affected users to uninstall the extension from their browser.

Uninstallation procedures are available for:

• Google Chrome
• Microsoft Edge
• Mozilla Firefox

Detecting the threat posed by malicious, potentially malicious, or risky browser extensions requires both continuous and risk-based approaches. A key challenge is the lag time between an extension appearing in a marketplace and its malicious functionality being publicly identified, disclosed, and subsequently removed from the browser marketplaces or updated to remove the malicious code. Therefore, your detection strategy must be carefully aligned with your specific objectives, available capabilities, and tolerance for detection volume.

Focus on the following key areas to define your strategy:

Clearly define what you aim to detect

• Extensions confirmed as outright malicious.
• Unsanctioned extensions that request broad or risky permissions (See Google’s white paper on risky permissions).
• Unsanctioned extensions that mimic names of well-known, legitimate vendor extensions (which may be malicious).

Assess your operational limits

• Can you accurately assess extension prevalence across your environment?
• What is your tolerance for high detection volume and false positives?

The combination of your defined scope, operational capacity, and tolerance is the bedrock upon which you will craft both high-fidelity and risk-based detectors.

High-fidelity detection

For high-fidelity detection, let’s consider two main scenarios:

Publicly disclosed malicious extensions

If an extension is publicly reported as malicious, and there is no reason to suspect it will be updated to a non-malicious version (such as the Phantom Shuttle malicious extensions), detection is straightforward and can be based solely on the extension’s ID in the environment:

Supply chain compromise

However, if an extension is compromised via a supply chain attack (e.g., the extension developer’s account is compromised), and there’s reason to believe the malicious code has been or will be removed in an update once the account is recovered, detection should combine the extension ID with the specific reported malicious version number.

A prime example is the 2024 supply chain attack against extension developers, where malicious code was uploaded in version 24.10.4 of the Cyberhaven extension but subsequently removed in version 24.10.5.

Risk-based detection

For a risk-based approach to detecting potentially malicious or risky extensions, we recommend first inventorying all existing extensions in your environment, using tools such as Osquery (for Chromium-based browsers and Mozilla Firefox), your EDR data, or the Admin console for your managed browsers (e.g.,Google Admin console’s app and extension usage details view). This list should detail the extension, its version, permissions, and usage across all users and devices in your fleet.

Gathering permissions and script information about extensions may require additional enrichment outside of your primary inventory tool. If so, this data can be collected in a couple of ways:

• Download the extension directly from the Chrome Web Store and extract permissions and referenced scripts from the manifest.
• Reference tools like Crxaminer or Chrome-Stats.

Crucially, after you have your comprehensive inventory, remove any unnecessary extensions to create a clean baseline, which will make anomalies significantly easier to spot.

Once you have established this clean baseline, you can proactively monitor for potential threats, such as the following:

New extension with risky permissions

If a new extension is installed and requests one or more high or medium-risk permissions, it serves as an early warning sign of a potentially malicious or risky extension requiring further investigation. This focused approach ensures that only new installations posing a threat due to requested permissions are flagged, rather than every new installation, providing a good balance between security and noise.

As an illustrative example, consider the Chrome extension Dark Theme – Dark Reader for Chrome, and its shortened manifest. This extension poses a significant security risk primarily due to its extensive and high-risk permissions, such as tabs and <all_urls>. These permissions grant it the broad capability to access and manipulate all browser tabs and websites, raising major security concerns that could be exploited for data theft and tracking user activity. Furthermore, its ability to inject scripts into any website allows it to read sensitive information, modify web content, and potentially steal user credentials. This extension was later reported as malicious after a bad update and was subsequently removed from the Chrome Web Store.

If a user were to install this or similar risky extensions, the following risk-based detection logic would be triggered:

Existing extension with permission or script changes (version update)

The core detection method here is similar to #1, but it specifically scrutinizes updates to an existing extension. We focus on changes to the permissions or content scripts listed in the extension’s manifest file. When an extension is updated, if the new version requests additional, previously unknown permissions or adds new scripts to the manifest, it’s a warning flag that may signal a malicious update.

Consider the Cyberhaven incident as a prime example. After the threat actor (TA) successfully authenticated their malicious OAuth app, they pushed a new, malicious version of the Cyberhaven extension. This new version (24.10.4) added a new content script, content.js, to the extension’s manifest. Our logic would have flagged this purely based on the unexpected change in the manifest file.

Potential lookalike extension

If a new extension is installed, check for close resemblance to approved or well-known extensions, as this could signal a potential malicious lookalike. For instance, your organization might only approve one specific extension, such as the official Dark Reader extension (extension_id: eimadpbcbfnmbkopoojfekhnkhdbieeh). By comparing the name of a new extension, like the malicious Dark Theme – Dark Reader for Chrome, to an approved one (e.g., Dark Reader), you can effectively identify potential lookalikes that pose an immediate or deferred risk.