# Browser Extensions With a Shared C2 on Your Pages Extensions your visitors installed, running on your pages, reporting to a shared C2 cluster and taking session data with them. Provenance: Corroborated by external research. Published: 2026-04-16. Updated: 2026-08-24. Most client-side security assumes the threat arrives through your page: a compromised dependency, an injected script, a tag somebody added. This one arrives through the visitor. The hosts we track here belong to a command-and-control cluster shared by a large family of malicious browser extensions. The extensions do the usual things — exfiltrate data, steal sessions — and they do it on whatever site the visitor happens to be on. Which is to say, on yours. ## Why you see it at all An extension with permission to run on a page can inject script into it. When it does, some of the requests that follow are attributed to your document, and your Content Security Policy sees them like anything else the page did. That gives you a view of something you otherwise have no visibility into at all — but a partial one. An extension that does its network work from a background context rather than the page is not covered, so the absence of these hosts in your reports is not evidence that no visitor is affected. ## What it means when you do see it Almost certainly not that your site is compromised. The likely explanation is one visitor with a hostile extension, and your pages can be entirely clean. That does not make it uninteresting. An extension with access to your pages can read what the visitor reads, including everything behind their login, and session theft is explicitly what this family does. For anyone running an account area, that is a session on your service being taken from a device you have no control over, which will look like a legitimate login when it is used. ## One cluster, many extensions The striking thing about this campaign is the concentration. Dozens of separately published extensions, presenting as unrelated tools, all reporting to subdomains of one registered domain: an API endpoint, a CDN, a chat endpoint, several themed like games and mining utilities. That structure is a defender's advantage. The operator publishes many small plausible extensions because individually they attract less attention than one ambitious one, and the shared backend that makes that cheap is also the thing that ties them together. Recognising the C2 identifies the whole family, including the extensions nobody has looked at yet. ## What to look for An unfamiliar host in your reports that correlates with no change on your side is the shape of this. Your files are identical, your dependencies are unchanged, and yet a page is talking to somewhere new — that pattern points away from your own supply chain and towards the visitor's browser. Volume is a useful signal too. Page-level compromises affect every visitor to that page, so the reports arrive in bulk. Extension traffic arrives from the fraction of visitors who installed something, so it looks like a handful of reports against a very small number of sessions. For an authenticated area, treat this as a session-integrity question rather than a page-integrity one. The page was fine; the browser it was rendered in was not. ## Indicators - 144.126.135.238 - api.cloudapi.stream - cdn.cloudapi.stream - chat.cloudapi.stream - cloudapi.stream - coin-miner.cloudapi.stream - crm.cloudapi.stream - gamewss.cloudapi.stream - goldminer.cloudapi.stream - herculessportslegend.cloudapi.stream - metal.cloudapi.stream - mines.cloudapi.stream - multiaccount.cloudapi.stream - tg.cloudapi.stream - topup.cloudapi.stream - wheel.cloudapi.stream ## Questions ### Why do extension connections appear in my CSP reports? An extension injecting a script into your page can cause requests attributed to your document, so your policy sees them and reports them. What is reported depends on how the extension does its work, so this is a partial view rather than a reliable inventory of extensions. ### Is my site compromised if I see these hosts? Not necessarily, and usually not. The likely explanation is a visitor with a hostile extension installed. Your pages can be entirely clean and still generate these reports. ### Can I do anything about a visitor's extension? Not directly. What you can do is know it is happening, because an extension with page access can read what the visitor sees on your site, including anything behind their login. ### Why does one C2 serve so many extensions? Because the extensions are one operation. A shared cluster is cheaper to run and lets an operator publish many small, plausible extensions rather than one that attracts attention, which is also why a single hostile domain can indicate a whole family.