A browser extension is not an app on a website. It is a more privileged thing sitting above every website. That distinction decides everything else in this article. Page JavaScript runs inside one site's sandbox. An extension with broad host permissions runs beside all of them, can read and write the content of each page you open, and can read the cookies that keep you signed in. It does not need to break any security control to do this, because the user granted it the access at install time and the browser is working correctly.
Four routes in, and the dangerous one is the quiet one
Direct publication to the store, at volume. In April 2026, Socket researcher Kush Pandya documented 108 Chrome extensions published under five publisher identities, with approximately 20,000 installs between them. The link between them was infrastructure: all 108 sent data to a single backend address. The behaviour split roughly three ways. Fifty-four harvested the signed-in Google account identity through the standard authorisation flow, collecting email address, full name, profile picture URL and account identifier. Forty-five contained a backdoor that opened attacker-chosen URLs when the browser started. The rest exfiltrated Telegram Web session data, including the session token, every fifteen seconds; stripped security headers on video sites; injected scripts into every page visited; or proxied ordinary functionality such as translation requests through the attacker's server. Attribution was not established.
The same pattern on Edge, at a larger scale. In June 2026 Microsoft removed 119 extensions from the Edge Add-ons store and suspended more than ninety developer accounts, attributing all of it to one threat actor it says had been active since at least 2021. Microsoft named the campaign StegoAd. The install base was up to 2.6 million, and Microsoft was careful to call that a ceiling rather than a victim count, stating that how many people were actually compromised is not known. We will use the same discipline here: install counts are an upper bound, always. The documented payload capabilities are the part that matters for this article: ad injection and hijacked affiliate commissions, redirected searches, theft of Google credentials and two-factor codes, theft of WordPress administrator logins, bulk cookie exfiltration, and a remote code execution backdoor.
Developer-account compromise through consent phishing, which is the one to worry about. In December 2024, extension developers received email appearing to come from Google, saying their extension had violated Chrome Web Store policy and faced removal. The link led to a genuine Google authorisation page for a malicious third-party application requesting one narrow permission: the ability to manage the developer's Chrome Web Store extensions. The narrowness is what made it look legitimate. The attacker then used that access to publish tampered versions of the developer's own extensions through the normal publishing pipeline. Read that again, because it is the important part. No password was stolen. No second factor was defeated. The developer's MFA was irrelevant, because they were not tricked into authenticating, they were tricked into authorising. The malicious update then reached every existing user through the auto-update channel they had deliberately chosen to trust. On counts, Hunters Security reported at least 35 extensions tampered with beyond the first disclosed case, and more than 2.5 million potentially affected users, though it does not state how either figure was derived, and the 2.5 million is almost certainly a sum of store-listed install counts. Other vendors reported between 16 and 36 extensions as the investigation widened. Cyberhaven published the first disclosure, of its own extension, on 24 December 2024, and Hunters states the broader campaign had been running for at least seven months before that. The payload established command and control and stole credentials, primarily targeting cookies.
Sideloading and management-plane misuse. Extensions can be installed outside the store, which is why Microsoft Edge publishes a policy captioned "Blocks external extensions from being installed" and another to configure permitted install sources. More importantly, the enterprise management channel is itself a route in. Chrome's extension policy supports a force-installed mode, described by Google as automatically installing extensions you specify without user interaction, and users cannot disable or remove extensions installed that way. Anyone who reaches your Google Admin console, Intune or group policy can push an extension silently and un-removably. The console that enforces your allowlist is a privileged attack surface in its own right.
What the install prompt does not tell you
Host permissions are the load-bearing grant, not the named permissions. Chrome's own developer documentation says that with host access to a site, an extension can make network requests from its service worker and extension pages, read sensitive tab properties including the URL, title and favicon, monitor network requests, and access cookies for that site. Everything an attacker needs for credential and session theft is in that list, and all of it travels with one grant.
Reading what your staff type into a login form is not a separate permission. It falls out of page access. A content script injected into a page reads the document, and the values of input fields are part of the document. Chrome's documentation never lists "read form fields" as a permission because it does not need to: it is covered by the ability to read and modify data on the pages you visit. This is the single most useful thing to explain to a colleague who is about to click Add to Chrome.
The permissions that matter most carry no warning at all. This is documented in Chrome's own permissions reference and it surprises most people. The cookies permission has no listed install-time warning string. Neither does the network request monitoring permission. Neither does the scripting permission. By comparison, the tabs permission warns that the extension can read your browsing history, and the debugger permission warns about reading and changing all your data on all websites. On top of that, warnings are suppressed by subsumption: Chrome's documentation states that the tabs warning will not be shown if the extension also requests access to all URLs. The net effect is that the install dialog systematically understates capability. An extension that already has broad host access can add cookie reading and request interception without triggering any new consent prompt.
One real control signal does exist in this area. When an update adds a permission that does have a warning string, Chrome disables the extension until the user accepts the new permission. A member of staff suddenly being asked to re-approve an extension they have had for two years is a genuine event and worth a message to whoever handles IT. The limitation is the obvious one: an extension that asked for access to all URLs on day one needs no further consent to change its behaviour entirely in a later update. That is precisely what made the December 2024 campaign silent.
Sessions, cookies and the limits of the flags you rely on
An extension with the cookies permission and host permissions for a domain can read that domain's cookies, including the ones marked HttpOnly. Both grants are required, and the host permissions decide which domains are in scope: Chrome's documentation states that if host permissions for a URL are not specified in the manifest, the call will fail. The important consequence for anyone who has been told HttpOnly protects session cookies: HttpOnly blocks client-side page scripts. An extension is not a page script. It is a separate, more privileged principal, and the cookies interface sits outside the page's sandbox. Chrome's documentation exposes HttpOnly to extensions as a readable property of the cookie object, which tells you what it is in this context: metadata the extension can see, not a barrier it has to get past.
HttpOnly and Secure are defences against cross-site scripting, not against extensions. Say that sentence to your developers. Both of the 2026 campaigns above corroborate it operationally: Microsoft documented bulk cookie exfiltration in StegoAd, and the December 2024 campaign's injected code was reported as targeting cookies primarily.
This is the structural reason an extension beats your authentication, whatever it is. A live session cookie is replayable from anywhere. It was issued after authentication succeeded, so it bypasses password strength, it bypasses MFA, and it bypasses passkeys, because none of those are involved any more. The Socket research gives the cleanest worked example: a session token lifted from a web application every fifteen seconds. That is session cookie theft with a permanent foothold in the browser instead of a one-time malware run, and it is one of the reasons MFA bypass remains viable in organisations that have done everything else right.
On autofill, the verified position is narrower than you may have read, and we will stick to the verified one. There is no documented interface that lets an extension read Chrome's own saved-password store. What an extension with page access can do is read values that are present in the page, which includes fields your browser or password manager has just filled in, and read keystrokes in those fields through injected script. The practical outcome is similar. The mechanism is different, and the difference matters if you are writing policy.
Manifest V3 is not the answer people think it is
One change in Manifest V3 is genuinely anti-malware: remotely hosted code is no longer allowed to execute. Chrome's documentation says remote code presents security risks by allowing unreviewed code to be executed, and that extensions may now run only JavaScript bundled in their package, which is subject to Chrome Web Store review. That raises the cost of swapping a payload after publication.
Everything else in Manifest V3 is about performance and the request-blocking model, not about credential theft. Service workers replaced background pages because background pages took up resources even when the extension was not running. The blocking form of the network request interface was deprecated because it required extensions to proxy all network traffic, at a performance and privacy cost. Its replacement is described by Chrome itself as "a safer alternative for many use cases", which is hedged wording that concedes it does not cover every case. Chrome also describes Manifest V3 as the first step in a multi-year platform vision. Nothing in the overview changes how host permissions are granted, which is the mechanism this entire article turns on.
The 2026 campaigns were Manifest V3. StegoAd migrated from Manifest V2 to V3 and kept operating. Its adaptation to the remote-code ban is instructive: the payload was hidden inside the shipped bundle, appended after the end marker of PNG icons and later concealed in WebP images and font files with code hidden in glyph ranges, then decoded with case swaps, digit swaps, Base64 and XOR. The code was technically bundled, therefore permitted, and reviewers did not see it. Meanwhile five of the 108 extensions in the Socket research used the new, safer replacement interface offensively, stripping Content Security Policy, X-Frame-Options and CORS headers from pages. The API introduced as the safe alternative was itself the tool.
The Electronic Frontier Foundation argued in December 2021 that the changes in Manifest V3 would not stop malicious extensions, while harming privacy and security extensions, and agreed only with the ban on remotely hosted code. That piece is commentary rather than evidence, and it predates the full rollout, so treat it as an argument that has aged well rather than as data. Separately, SquareX demonstrated in November 2024 that extensions built on Manifest V3 could still steal live video streams from collaboration platforms, add unauthorised collaborators to private code repositories, and reach cookies, history, bookmarks and download history. That is a capability demonstration with no stated method, so no numbers attach to it.
The business takeaway is one sentence. "This extension is Manifest V3" is a compatibility statement, not a security assurance.
The control that actually helps
Chrome's extension settings policy can do three things, and almost everybody uses only the first. It can set an installation mode per extension or as a default for everything. It can block extensions by the permissions they request. And it can restrict which websites any extension may interact with.
Start with the default, because the default is permissive. If no mode is defined, the mode is allowed, which means users can install anything from the Chrome Web Store. For a small business the workable configuration is to block the wildcard default, then allowlist the handful of extensions your staff genuinely need by their extension identifiers.
Then set the control nobody uses, which is the blocked hosts list. Google's wording is that it "Prevents extensions from interacting with specified websites". This is the recommendation worth the price of the article, because of what it changes about the question you are asking. Allowlisting asks "is this extension trustworthy?", which nobody can answer reliably at install time and which the December 2024 campaign shows cannot be answered durably at all, because a trustworthy extension can become malicious through an update. The blocked hosts list asks instead "which sites may any extension touch?", and that is an inventory question you can answer in an afternoon. Block all extensions from interacting with your banking portal, your payroll system, your webmail and your identity provider, and an extension that later turns malicious still has nothing to work with on those sites. There is a companion allowed-hosts list which takes precedence over the blocked list for the same sites, so use it sparingly and deliberately. On format, the host patterns need a scheme, hostname and top-level domain, the subdomain is optional, and paths including a trailing slash are invalid.
One honest caveat on that recommendation. Google's documentation says the setting prevents interaction with the specified sites. It does not spell out whether that also blocks the cookies interface for those hosts or only script injection into their pages. We have not verified the mechanism, so we are not going to tell you it is a complete cookie-theft defence. It is the strongest available control in this area and it is worth configuring today, and if your developer can confirm the cookie behaviour in your Chrome version, confirm it.
Blocking by permission sounds better than it is. The documented example in Google's own help is blocking extensions that connect to USB devices. The permissions that matter here, cookies, network request interception, scripting and above all broad host access, are exactly the ones legitimate password managers, ad blockers and grammar tools need. Blocking by permission will break tools your staff rely on, and they will find a way around you. Say no to this one.
Edge exposes the same family of policies, with install allowlists, blocklists, a silent-install list, a general extension settings policy, the external extension block, and install source configuration. Firefox has its own extension settings policy, but we did not verify its field list and we are not going to claim it matches Chrome's.
Detecting it, and what to do when you find it
The following is our reasoning from documented attacker behaviour, not a published framework. We say so because there does not appear to be an authoritative vendor-neutral detection guide for this threat, and a ladder presented as a standard would be a misrepresentation.
The way researchers actually find these campaigns is infrastructure clustering, and you can afford the cheap half of it. Socket linked all 108 extensions through a single shared backend address. The December 2024 campaign was mapped across at least ninety malicious domains and thirty addresses. You are not going to run that analysis. What you can do is the four cheaper steps. Keep an inventory of what is installed and what permissions each extension declares, which is free local data and the only input you can rely on. Alert on change rather than on state: a new extension, a new permission, a re-consent prompt. Watch browser egress for unfamiliar destinations and for regular fixed-interval beaconing, since a session token exfiltrated every fifteen seconds is a distinctive traffic shape. And if your business publishes an extension of its own, review the third-party application grants on the developer's Google account, because that is the exact control that would have stopped the December 2024 campaign.
Do not expect to see anything by looking. StegoAd delayed activation for days, validated targets server-side before delivering a payload, ran on only ten per cent of installations in some variants, failed over across more than ten command-and-control domains, and went dormant for an extended period when developer tools were open. That last one pre-empts the most likely self-help attempt: an owner-manager opening the inspector to see what the extension is doing will see nothing. Store takedowns are a lagging indicator too, not detection. Microsoft removed 119 extensions belonging to an operation it says had been running since at least 2021.
The remediation point is the most important operational line in this article. Treat a malicious extension as a session compromise, not a malware removal. If cookies were exfiltrated, uninstalling the extension and changing passwords does not evict the attacker, and neither does enrolling a passkey, because the stolen session already exists and does not need to authenticate again. What evicts them is revoking sessions across your applications, from outside the compromised browser. The Socket researchers' own advice followed exactly this logic: remove the extensions, and then log out of all web sessions from the mobile application, which is to say revoke out of band. For the general case of what a credential change does and does not clear, see what survives a password reset.
And watch the exposure that follows. Credentials and session material taken by an extension end up in the same places as everything taken by infostealer malware, which is to say in stealer logs and on the channels described in stolen credentials on Telegram. Seeing your domain appear in fresh data is often the first reliable evidence that something in a browser is sending data somewhere it should not.
What to do about it this quarter
Inventory what is installed. You cannot make a decision about extensions you cannot see. Count them, and look at the permissions on the ones with access to all sites.
Set the wildcard default to blocked and allowlist what you need. Unmanaged Chrome permits arbitrary store installs, and most small businesses are unmanaged by default rather than by decision.
Configure the blocked hosts list for your crown jewels. Banking, payroll, webmail, identity provider. This is the one that keeps working after an allowlisted extension changes hands.
Tell staff what a re-consent prompt means. If Chrome disables an extension and asks them to approve a new permission, that is not a nuisance, it is a reportable event.
If you publish an extension, audit the developer account's third-party application grants, and do it this week. That single review is the control that the December 2024 campaign defeated by not being performed.