Mellowtel: The Hidden Proxy Network Inside Everyday Browser Extensions​

How the Mellow.tel SDK turns Chrome Extensions into Residential Web-Scraping Nodes

Ordinary browser extensions can ask for extraordinary access.

That access is often justified by the extension's visible feature: saving images, managing tabs, tracking prices, downloading media, changing video speed, or adding a timer to the browser. But when a utility extension also bundles a third-party monetization SDK, the permissions granted for one purpose can quietly become infrastructure for another.

Our research into extensions embedding the Mellowtel SDK found exactly that pattern. Mellowtel, distributed as the mellowtel npm package and published as mellowtel-js on GitHub, can enroll a user's browser into a remotely controlled web-scraping network. Once installed inside a browser extension, the SDK can receive scraping jobs from Mellowtel-operated infrastructure, load third-party pages through the user's residential IP address, remove web security headers to make hidden frames load, and transmit page content back to remote endpoints.

From our proxy intelligence, we initially saw approximately 90,000 IP addresses associated with Mellowtel activity. After we spoke with Google's research team, Google reportedly took action against affected extensions while allowing extensions that removed the SDK to remain. Following that action, Mellowtel's observed IP count dropped to roughly 15,000 to 18,000 IPs, with the current observed count around 18,000. The geographic distribution remained broadly consistent: 43% of observed IPs were based in the United States, followed by China at 11% and Great Britain at 9%.

The issue is not just that users may be opted into a bandwidth-sharing or scraping business model. It is that the browser is a privileged place to run that model. A browser extension with broad permissions can see and alter pages, strip protections that websites intentionally set, and issue network requests in ways normal web pages cannot.

What Mellowtel Does

Mellowtel is presented to extension developers as a way to monetize their browser extensions. In practice, the SDK gives the operator a remote command channel into the installed extension.

The extension's background context opens a WebSocket connection to:

ws.mellow.tel

That connection is keyed by details including a device identifier, the host extension's ID, and the user's measured connection speed. Mellowtel's servers can then push crawl jobs to the browser. The extension performs those jobs using the user's browser and residential IP address, then posts harvested page content to an operator-controlled endpoint.

For the user, none of this necessarily looks like the feature they installed. A timer, calculator, screenshot tool, image downloader, or LinkedIn helper may continue to behave as expected while the bundled SDK performs separate network activity in the background.

Why Should I Care About Bandwidth Sharing?

Residential IP addresses are valuable because they look like normal users. Many sites treat traffic from a home connection differently from traffic coming from a cloud datacenter. That is why residential proxy networks are commonly used for web scraping, account automation, fraud, ad verification, sneaker bots, and other activity where reputation matters.

When a browser extension turns a user's device into a scraping node, the visited websites see requests coming from that user's IP address. Any rate limits, blocks, abuse complaints, or legal concerns can land on the user or their network, even though the requests were initiated by an extension SDK they may not know is present.

That makes disclosure critical. Yet most of the extensions we reviewed did not publicly disclose the presence of the Mellowtel SDK in a way an ordinary user would reasonably understand before installing.

The Security Problem: More Than Bandwidth Sharing

The Mellowtel SDK does not only send background web requests. Its implementation uses browser-extension privileges in ways that materially weaken the security model of the web.

1. It strips website security headers

To load arbitrary third-party websites inside hidden frames, the SDK installs declarativeNetRequest rules that remove important response headers, including:

• Content-Security-Policy
• Content-Security-Policy-Report-Only
• X-Frame-Options
• Cross-Origin-Embedder-Policy
• Cross-Origin-Opener-Policy
• Cross-Origin-Resource-Policy

These headers exist for a reason. They help websites prevent clickjacking, cross-origin data exposure, injection attacks, and unsafe framing. Removing them across broad URL patterns undermines protections that site owners intentionally deployed.

The SDK also modifies request and response behavior for its own fetches, including stripping the Origin request header and injecting Access-Control-Allow-Origin: * on responses. In effect, the extension is using its elevated position to defeat parts of the browser's same-origin and CORS protections.

2. It runs with full-page access

The SDK's content scripts are designed to run on:

<all_urls>

They also run in all frames and at document start. This gives the SDK visibility into pages the user visits and lets it inject hidden iframes, inspect page DOM, and interact with page content.

That permission model may be normal for a small class of browser extensions whose primary purpose requires broad page access. It is far harder to justify for ordinary utilities such as timers, calculators, screenshot helpers, image downloaders, and media tools.

3. It can inject and manipulate browser state

The reviewed SDK source includes behavior for injecting cookies, localStorage, and sessionStorage into target pages before loading them. It also includes modules capable of scripted DOM interaction such as clicks, inputs, and operator-supplied JavaScript execution inside scraped pages.

That turns the user's browser from a passive network relay into an active automation environment.

4. It can change behavior after store review

The SDK receives work at runtime over a WebSocket and includes a remote switch mechanism that can enable or disable behavior per extension. This means the visible extension package reviewed by a store is not the full operational picture.

The same extension can be quiet during review, then later receive different targets, scraping instructions, or injected scripts from a remote operator without a new store submission.

A Confused-Deputy Vulnerability

Beyond the business model, our review identified a security flaw in the SDK: an unauthenticated postMessage path that can cause the extension's privileged background context to issue arbitrary HTTP POST requests.

The content script registers a window message listener for a message type named saveBurkeResult. That listener accepts attacker-controlled fields including apiEndpoint and resultToSave, then forwards them to the extension background context. The background worker then calls fetch against the supplied endpoint with the supplied body.

In plain terms, any website visited by a user with an affected extension could send a crafted message to the page and cause the extension to make an outbound POST request from the user's IP address and extension context.

The response is not returned to the attacking page, so this is a blind write or relay primitive rather than a read primitive. But the core issue remains serious: an untrusted website can drive privileged extension behavior and cause network requests that the website itself would not normally be allowed to make.

That is the classic confused-deputy pattern. The browser extension has authority. The website does not. The website tricks the extension into using its authority on the website's behalf.

Observed Scale

SecureAnnex previously documented approximately 245 affected extensions across Chrome, Edge, and Firefox with roughly 1,000,000 total installs. Our initial proxy and extension intelligence showed roughly 90,000 Mellowtel-associated IP addresses observed in the wild. After we spoke with Google's research team, Google reportedly took action, and extensions that removed the SDK appear to have been allowed to remain. Mellowtel's observed IP count then fell to roughly 15,000 to 18,000 IPs, with the current observed count around 18,000.

Observed Mellowtel IP distribution:

• United States: 43%
• China: 11%
• Great Britain: 9%

The United States remained by far the largest observed source country, representing nearly half of the Mellowtel IPs we saw. China and Great Britain were the next largest sources.

Chrome Extension Categories We Observed with Mellowtel and <all_urls>

As of July 30, 2026, the current observed Chrome extension dataset still included extensions with the Mellowtel SDK and the <all_urls> permission. This is not a complete ecosystem-wide inventory, and we are not listing individual extensions here except where the user-safety concern is especially direct.

Notable extension types in the current dataset include:

• Timers, alarms, pomodoro, and focus tools
• Calculators, QR tools, color pickers, and other small browser utilities
• Screenshot, image-downloader, audio-recorder, and media-downloader tools
• Video playback helpers and ad-blocking utilities
• Stock, crypto, and price-tracking extensions
• LinkedIn and social-network workflow tools
• Emulators, tab utilities, and novelty extensions
• Extension-support or monetization helper extensions
• Education and homework tools

Informed Consent and Children

One especially notable example is SparxSolver, a math homework solver for the Sparx platform. That matters because this is not only a disclosure question; it is also an informed-consent question.

Consent cannot be meaningful if the person supposedly consenting is a child who does not understand that a homework helper may also turn their browser and home IP address into part of a residential scraping network.

Even if an extension presents a consent screen or describes a monetization arrangement, that does not resolve the issue for child users. Children are unlikely to understand the technical consequences of proxying traffic, stripping security headers, loading hidden frames, or allowing third-party scraping jobs to run through their browser. They also cannot reasonably assess the risks that abuse complaints, rate limits, blocks, or other consequences may be associated with their household connection.

For an education-focused extension such as SparxSolver, the expected user base makes this problem sharper. The visible purpose is help with schoolwork. The hidden or secondary purpose is participation in a web-scraping network. Those are not equivalent purposes, and consent to the first cannot be treated as informed consent to the second when the consenting entity may be a child.

Why Disclosure Is Not Enough on Its Own

Some extension monetization systems are framed as a trade: the user gets a free extension, and the developer gets revenue by sharing some of the user's idle bandwidth. Even when that trade is disclosed, browser extensions deserve a higher bar than ordinary desktop bandwidth-sharing apps.

A browser extension does not just have an IP address. It can have visibility into pages, frames, cookies, storage, requests, and response headers. It can also hold permissions granted under the assumption that they are needed for the extension's visible feature.

That makes vague language about "supporting developers" or "monetization" insufficient. Users need to know when an extension is turning their browser into scraping infrastructure, what sites may be accessed, what data may be collected, and what security controls may be bypassed to make the scraping work.

Store reviewers also need to be able to reason about runtime behavior. A remotely commanded SDK with a kill switch, hidden iframes, broad header modification, and all-URLs content scripts creates a review problem: the extension submitted to the store is only one part of the system.

Conclusion

Mellowtel shows how thin the line can be between a browser extension and a residential proxy node.

The user installs a tool. The developer adds a monetization SDK. The SDK receives remote jobs, strips headers, injects hidden frames, accesses pages across the browser, and sends traffic through the user's IP address. To the target website, the request looks residential. To the user, the activity may be invisible.

In this case, the traffic is not only coming from proxy servers or datacenter ranges. It is coming from ordinary browsers through ordinary extensions, often with little public disclosure and with security consequences that go well beyond bandwidth sharing.

Next Steps: Identify Residential Proxy Infrastructure Behind Consumer IPs

Residential proxy traffic can originate from ordinary consumer networks, making it difficult to distinguish from normal user traffic. The Spur IP Intelligence Platform identifies residential proxy infrastructure and provides context about the service and network behind a connection.To see how Spur identifies this infrastructure, explore Residential Proxy Detection, or get started for free with Spur Community to investigate IP addresses today.

Sources and Methodology

This post is based on review of the published mellowtel-js source code, the mellowtel npm package, 300k extension manifests, observed proxy intelligence, and prior public reporting.

References

• Mellowtel SDK source: github.com/mellowtel-inc/mellowtel-js
• Mellowtel npm package: npmjs.com/package/mellowtel
• Prior public analysis: SecureAnnex, "Mellow Drama"