22 Browser Extensions Are Running Operator Code Inside Corporate Sessions. Your EDR Cannot See the Room They Are In.
The interesting fact in the CRXfiltrate disclosure is not that 22 malicious browser extensions exist. It is that across the environments where 7AI hunted for them, the detection gap was, in the researchers' own words, "essentially nothing". The extensions were running operator-controlled code inside authenticated corporate browser sessions, and the endpoint security that those same organizations had bought and tuned reported clean. This was not a tuning problem. The sensors were pointed at a different room.
That distinction is the whole post. When EDR misses something because a rule was too loose or a threshold was set wrong, you have a detection-quality problem, and you fix it by tuning. When EDR misses something because the activity happens in a region the sensor model was never architected to observe, you have a coverage problem, and no amount of tuning closes it. CRXfiltrate is the second kind, and the region it operates in is the one place most security programs have quietly agreed not to own: the post-authentication browser session.
The Disclosure
On May 14, 2026, 7AI Threat Research published CRXfiltrate, a writeup of a cluster of 22 confirmed malicious Chrome and Edge extensions (23 tracked) with a documented install floor of more than 85,000 users. The seed extension, a color picker called MyColorPick, carried roughly 10,000 of those installs on its own.
The cluster is not new, which is the part worth sitting with. The same operation was independently named "Phoenix Invicta" by researcher Wladimir Palant in January 2025; sixteen months later it is larger, actively maintained, and still operating. At the time of disclosure, listings were still live and installable: "Easy Dark Mode" on Chrome (unlisted but reachable by direct link), and both "1-Click Color Picker: Instant Eyedropper" and "AdBlock for Youtube: SkipAds" on Microsoft Edge. A separately operated "Color Picker · Eyedropper" extension with roughly 400,000 users is a distinct actor and is not part of this cluster, which matters because conflating the two inflates the count and misattributes the tradecraft.
This is not a smash-and-grab. 7AI found source-code comments referencing project ticket numbers above 390, a Webpack-bundled and versioned payload (m3011.js, measured between 111 and 135 KB), and a fingerprint that validated against a 265-extension corpus with zero false positives. The researchers' framing is the right one: "This is software product engineering, not a fire-and-forget malware drop."
What Actually Runs, and Where
Manifest V3 was positioned by Google as the fix for exactly this threat. The headline restriction is that an extension can no longer fetch and execute remote code. CRXfiltrate satisfies that restriction precisely and bypasses its intent, because it never runs the operator's code in the extension context at all.
The mechanism is worth walking through, because the architecture is the point:
- The extension ships a
declarativeNetRequest ruleset that strips the Content-Security-Policy and X-Frame-Options headers from every HTTP response the browser receives.
- A content script then injects a
<script> element into the DOM of whatever page you are visiting.
- That script fetches operator-controlled JavaScript from a command-and-control server and executes it in the page's own realm.
The extension never runs the remote code. The page runs it. Manifest V3 governs what the extension may execute; it does not govern what the page executes once an extension has stripped the page's defenses and handed it a script tag. The operator gets arbitrary code running inside the same realm as your authenticated session to whatever site you are on, which is where the SSO tokens, the session cookies, and the live credentials already live.
Now look at what is left on the host for EDR to find. No file is dropped. No process is spawned outside the browser. No registry key is written. Exfiltration travels as ordinary HTTPS: the visited domain, page title, install UUID, and extension ID ride out as URL query parameters, and the response body carries the next-stage payload back in. At the wire it is indistinguishable from normal web traffic to an uncategorized domain. 7AI states the coverage problem plainly: "EDR is architected for process behavior, file changes, and network anomalies at the host level. A browser-internal injection that uses the browser's own network stack is invisible to that telemetry model."
Why the Sensor Model Misses It
I spent eight years in Navy EOD, and the discipline that transfers most directly to security work is not bomb knowledge. It is sensor coverage. Before you approach anything, you decide what your sensors actually observe and, more importantly, what they structurally cannot, because the gap you do not map is the one that kills you. A render-safe procedure built on the assumption that your detector sees the whole device is worse than no procedure, because it manufactures confidence in a region you were never watching.
EDR makes a specific bet about where adversaries operate. It instruments process creation, file system changes, and host-level network behavior, and it does so very well. CRXfiltrate does not contest any of that. It simply operates one layer up, inside the JavaScript runtime of a process EDR already trusts, using a network stack EDR already permits. The adversary is not evading the sensor; the adversary is standing somewhere the sensor was never built to look. This is the same structural blind spot I described in a recent piece on agentic identity bypass: a security stack tuned to watch for human-shaped, host-shaped threats reports clean while something operates in a shape it was never designed to register.
The premise that the post-authentication browser session is where the attack surface moved is not new either. I argued it in the post on the Storm infostealer, which steals the session cookies and tokens already sitting in the browser and never touches the password or the second factor. CRXfiltrate is the same room seen from the opposite side: Storm reaches into the session and takes what is there, while CRXfiltrate puts a live execution engine inside the session and runs whatever the operator sends next. One is theft from the room; the other is occupancy of it. Both are invisible to a sensor that stops at the process boundary.
The browser session is now an execution environment, and it sits in a governance no-man's-land. Endpoint security owns the host and its telemetry stops at the process boundary. Network security sees TLS to a domain it has not categorized and nothing more. IT does not own it either, because the extensions are user-installed and, in practice, unmonitored. Three functions each have a defensible reason the browser tab is not theirs, and the sum of those reasons is that nobody owns the room where the operator's code is running.
This Is Not a New Class of Failure
If CRXfiltrate were a one-off, you could treat it as a curiosity. It is not. On December 24, 2024, attackers published a malicious build of the Cyberhaven extension after phishing a Chrome Web Store OAuth token. The OAuth authorization bypassed MFA cleanly, because MFA guards authentication, not authorization, and the malicious build passed Chrome Web Store review on its way out. That is the same gap I wrote about with malicious VS Code extensions and the missing security perimeter: marketplace review cannot distinguish legitimate functionality from the same functionality turned against the user, because both ask for the same permissions. Sekoia later tied the Cyberhaven incident to a broader campaign of roughly 36 extensions affecting around 2.6 million users. A separate cluster documented in February 2025 reached roughly 3.2 million users. The pattern keeps recurring: five extensions impersonating Workday and NetSuite surfaced in January 2026, and two credential-stealing extensions pulling data from more than 170 sites surfaced in December 2025.
The environment that makes this durable is well documented. LayerX's 2025 Enterprise Browser Extension Security Report found that 99% of enterprise users have at least one extension installed and 53% run more than ten. More than half, 53%, run extensions with high or critical permission scopes. The provenance is worse than the permissions: 54% of extension publishers have no verifiable identity beyond a generic Gmail address, and 51% of installed extensions have not been updated in over a year. The report's own summary is that extensions are "rarely monitored by security teams or controlled by IT," which is the governance gap stated as a finding rather than an argument.
There is one more number from that report that should change how you think about response. 26% of enterprise extensions are sideloaded, meaning they were never installed from a store and a store cannot remove them. This is why takedown-centric response is theater. When Google or Microsoft delists a CRXfiltrate extension, the listing disappears; the extension already installed in a user's browser keeps running, keeps phoning home, and keeps executing whatever the C2 returns. Store removal is not uninstallation, a point I made about platform accountability in the piece on the Steam malware investigation: delisting an item treats the symptom while the distribution channel and the installed base both stay intact. 7AI makes the same point about the payload itself: "Blocking the response prevents monetization. It does not prevent surveillance." A delisting changes the marketing funnel for new victims. It does nothing for the population already compromised.
What To Actually Do
The procurement question that no vendor data sheet answers is the one worth carrying into your next renewal: what fraction of your execution surface does your telemetry model actually instrument? Not how good is the detection, but what is in frame at all. CRXfiltrate is a clean test case, because an honest answer for most EDR deployments is that the browser's JavaScript runtime is entirely out of frame.
Five concrete moves, in order of leverage:
- Inventory the browser, not just the host. Build a real inventory of installed extensions, their permission scopes, their publisher identity, and their update recency. The LayerX numbers above are your baseline expectation; assume your own environment looks similar until you have measured it. This is the shadow-IT surface I argued for treating as a first-class vendor question in my post on self-hosted AI and the vendor questionnaire, and extensions belong on the same list.
- Enforce an extension allowlist through enterprise browser policy. Chrome and Edge both support
ExtensionInstallAllowlist and ExtensionInstallBlocklist via managed policy. An allowlist is the only control that meaningfully addresses the 26% sideload population, because it governs what is permitted to run rather than what a store is willing to host.
- Treat the browser session as an asset that needs its own telemetry. Whether you get this from a managed browser, a browser-security extension, or browser-native logging, the requirement is the same: visibility into what executes inside the tab, not just what crosses the host boundary.
- Stop counting takedowns as remediation. A delisting is a notification that you have an installed-base problem, not a fix for it. Remediation means forcing the extension off the endpoints that already have it.
- Put the coverage question in your DDQ. Ask vendors to state, in writing, what their telemetry observes inside the browser process. The useful answers are the specific ones; the marketing answers will mention "comprehensive endpoint visibility" and stop there.
The CRXfiltrate cluster was named once in January 2025 and is still installable on Microsoft Edge today, sixteen months later, because the response to it ran on the takedown clock while the cluster ran on a release cycle with ticket numbers above 390. The first organization to actually close this gap will not do it by buying a better detector. It will do it by deciding, explicitly, which function owns the browser tab, and then funding that function to put a sensor inside it.
