A sprawling set of browser extensions has quietly reshaped how tens of thousands of users’ browsers operate, turning many devices into covert web-scraping agents for a paying audience. A cluster of 245 extensions across Chrome, Firefox, and Edge has been found to override key security protections and steadily siphon off web access to a paid service, all while masquerading as routine tools for bookmarking, clipboard management, volume control, or even random-number generation. At the heart of this operation is an open-source JavaScript library that developers embed in extensions to monetize their work, setting the stage for a far-reaching set of privacy and security implications that affect individual users and corporate networks alike. The findings paint a picture of a monetization model that blurs the lines between legitimate software enhancement and covert web access, raising urgent questions about how web platforms vet extensions and how users can protect themselves when thousands of smaller add-ons operate with broad permissions.
What the discovery reveals about the extensions and their operation
Across the Chrome, Firefox, and Edge ecosystems, a sizable cadre of extensions has appeared with a shared core: the MellowTel-js library. This open-source library provides a framework for developers to monetize their extensions by enabling traffic-sharing and data-access capabilities that can be deployed to serve paying clients. The practical effect of this library on the user’s browser is more complex than a simple utility enhancement. The extensions in question perform a range of benign-seeming tasks, from organizing bookmarks and clipboard data to increasing playback volume or generating random numbers, which superficially appears harmless and routine. Yet beneath the surface, the library configures and sustains a network of activities that operate beyond the visible scope of the extensions’ user-facing features.
A key throughline connecting all of these extensions is the library’s architecture, which is designed to facilitate the monetization process by routing certain browser activities toward a centralized commercial objective. The monetization model is explicit in the library’s framework: developers receive a portion of the revenue generated by enabling traffic and data-sharing activities, while the library’s maintainers retain the remainder of the proceeds. In practice, this model translates into a mechanism by which the installed extensions participate in a broader, pay-to-access data ecosystem that leverages the installed base of users to fulfill external data-access requests.
In this arrangement, the monetary incentive to monetize user traffic can inadvertently weaken the user’s own browsing protections. A researcher examining the codebase and the operational patterns of the library identified a troubling chain of events: the library can initiate a websocket connection to a remote server, which is hosted on a major cloud provider, to collect metadata about the user’s session. Specifically, the websocket can relay data such as the user’s location, available bandwidth, heartbeat signals, and ongoing status of the extension. This real-time telemetry is paired with an additional step in which a hidden iframe is injectively loaded into the page the user is viewing. This iframe then connects to a curated list of websites specified by the remote server, enabling activity that remains invisible to the user’s browser interface and, crucially, invisible to standard browsing protections.
The architecture that enables this behavior hinges on permission requests that extend beyond typical extension operations. In some cases, the library required the browser’s declarativeNetRequest view to be added or to be accessed via the extension’s manifest. These permissions enable the dynamic alteration of web requests and responses as they occur, effectively giving the extension the power to tamper with security protections that would ordinarily guard a page’s integrity. By manipulating how web servers respond, the library can selectively suppress security headers and then restore them after a page has loaded, thereby undermining standard security controls that would otherwise prevent intrusive content or other types of cross-origin activity.
This three-pronged approach—telemetry via a websocket, invisible iframe loading, and on-the-fly modification of security headers—presents a layered risk to users. On one level, there is a direct privacy concern: data about the user’s environment and behavior is being channeled to a third party, raising alarms about how much of a user’s private browsing footprint is being captured and transmitted. On another level, the manipulation of security headers and the possibility of injecting content into an active webpage create pathways for more sophisticated security vulnerabilities, including the prospect of cross-site scripting or other forms of exploitation that would typically be mitigated by robust browser protections.
From the user’s perspective, the exact websites being opened through the hidden iframe are not visible within the user interface. There is no straightforward, transparent method by which end users can verify or audit which sites are being accessed as part of the library’s operation. This opacity makes it difficult for individuals or organizations to determine whether the extension is acting within expected bounds or venturing into potentially risky territory. The combination of ambiguous site access, real-time telemetry, and the occasional reversal of security headers creates a complex risk landscape that users and administrators must navigate without easy, clear indicators of what is happening under the hood.
On the monetization front, the library’s founder argues that the objective is to share users’ bandwidth in a way that avoids stuffing affiliate links, unrelated ads, or the collection of personal data. He contends that the primary motivation for companies to purchase traffic is to access publicly available data from websites in a reliable and cost-effective way, a claim often framed as privacy-conscious in spirit but executed with a model that raises questions about user autonomy and consent. The owner also points to a revenue split in which developers receive 55 percent of the generated income while the library’s maintainers retain the rest. While these remarks provide a tone of principled data-sharing and efficiency, critics argue that the practical reality is far more invasive, given the hidden nature of the operations and the potential for misuse through compromised sites or misconfigured deployments.
Despite assurances to the contrary, the discovery has raised immediate concerns among security researchers and privacy advocates about the potential consequences for everyday browsing. The specific behavior of initiating a websocket connection to a centralized service and loading an invisible iframe from a remote server creates a dual threat: it exposes a latent privacy risk and creates an attack surface that could be exploited to compromise system integrity or to exfiltrate sensitive data that users assume remains under the browser’s control. In addition, enterprise networks that enforce strict code and site controls may face added stress as the extensions attempt to operate in environments with tightly restricted security policies, exposing a broader class of vulnerabilities for corporate stakeholders who rely on robust, policy-driven browsing ecosystems.
This pattern of behavior bears a notable resemblance to a prior episode in browser extension history, reminding observers of a 2019 incident in which a large number of extensions reportedly collected users’ entire web activity and transmitted it to a data analytics domain used by a third party. The legacy case highlighted how extensions can act as multipliers for data collection when the underlying code and permissions are allowed to operate without stringent oversight. The continuity between the historical case and the current findings underscores a recurring challenge in browser ecosystems: the tension between enabling useful, freely available extensions and maintaining a secure, privacy-preserving browsing environment for users who often lack visibility into what these tools are truly doing in the background.
In the wake of these findings, several extensions that embed the MellowTel library have seen a mixed status among the user community. Some Chrome extensions were found to be inactive, either due to explicit malware removal or as a result of the developers removing the library from their codebase in subsequent updates. A subset of Edge extensions continues to operate but with a reduced footprint, and a portion of Firefox extensions identified in the analysis has likewise moved toward inactivity or removal of the library. The evolving status of these extensions highlights not only the fragility of the monetization approach but also the ongoing risk for users who still rely on older or unupdated builds. The precise list of affected extensions has been documented by researchers, and while some have been neutralized or partially disarmed, others continue to present exposure risks depending on their configuration and the environments in which they operate.
In this broad context, the central questions revolve around how such a monetization framework could proliferate across major browser ecosystems without triggering broader safety interventions sooner. The fact that a diverse set of extensions—across multiple browsers and a wide array of everyday tasks—incorporates the same foundational library points to a systemic weakness in how extensions are vetted and monitored for behavior that veers into data-sharing or content-injection territory. It also raises fundamental concerns about user consent, transparency, and the right of individuals to know when their protocols or security settings are being altered by third-party code embedded in everyday tools they installed for convenience or productivity.
The threat model: how paying customers gain leverage and what data could be exposed
The core threat emerges from a relationship where paying clients subscribe to access to browser activity, effectively using a distributed network of extension users to source data or reach specific web pages on demand. In this arrangement, clients specify the URLs or web resources they want to access, and the library orchestrates this access by leveraging the installed base of extensions that are running the library. The operational model described by researchers involves a multi-tier workflow: the client issues a request to retrieve data or access to particular web pages; the MellowTel-based network routes this request to the active extensions that have the library loaded; the extensions then execute the requested access path, leveraging the user’s session and browser state to complete the task. In doing so, the extensions effectively become a distributed set of browsing agents that can be utilized to harvest publicly accessible data, collect site-specific information, or retrieve page content in bulk for external consumption by paying customers.
A key element of this threat model is the reliance on the web as a data access gateway. By turning browsers into scraping engines, the model shifts the burden of data collection away from centralized servers and onto the end-user environment. The scale of this operation is amplified by the breadth of the user base—the more devices the extensions are installed on, the greater the potential pool of web resources that can be accessed in parallel. The capacity to parallelize requests—reported by proponents of a related service as being able to reach tens of thousands of requests within minutes—illustrates how quickly data can be amassed when a large, distributed volunteer workforce is effectively drafted into a paid data-extraction workflow. This dynamic can rapidly accumulate a per-volume advantage in competitive data markets, especially in scenarios requiring access to publicly available data across a range of sites and platforms.
The relationship with Olostep, a company describing itself as offering a web-scraping API that emphasizes robust performance and low detection risk, adds another layer of complexity to the threat model. The claim that Olostep’s service “avoids all bot detection” and can execute a large number of requests in a short time suggests an alignment between a service designed to optimize data collection and the library’s capacity to mobilize the extension network. The analysis points to a potential dependency: the extensions’ capacity to fulfill Olostep’s requests by distributing them across the active MellowTel-enabled installations. The implication is that the extensions act not merely as passive tools but as active participants in a commercial data-collection pipeline, with the user’s own browser resources being leveraged to support the client’s data access strategy.
From a privacy and security perspective, this threat model culminates in several high-impact scenarios. First, there is the possibility that the data being collected includes sensitive, sensitive-looking telemetry: the user’s approximate location, the bandwidth status of the session, heartbeat signals that reflect ongoing activity, and the functional status of extensions. Even if these data points are benign in isolation, their aggregation and correlation with a user’s browsing behavior can reveal patterns, preferences, and behavioral fingerprints that extend beyond what users intend to share with third-party services. Second, the injected iframe introduces a channel through which content could be loaded from external domains without the user’s awareness. The content loaded in this hidden iframe could, under certain conditions, interact with the host page in ways that might bypass typical content security configurations, or it could serve as a conduit for further data interactions, if not outright injection of code, to influence the user’s browsing experience and potentially expose the user to additional risk.
Another dimension of the threat model concerns enterprise environments, where corporate devices and networks are safeguarded by a stack of protective controls and strict policies about what code can execute or what sites can be accessed. When a user installs an extension that integrates the MellowTel library, the extension inherits capabilities to intercept and modify web traffic. The potential to alter security headers in real time means that even well-protected corporate networks could be exposed to a broader attack surface, particularly if the extension is allowed to operate within a highly controlled browsing context but still exerts influence on how pages are loaded and interpreted. In large organizations, the presence of such extensions can complicate security monitoring, create blind spots for threat detection, and undermine the integrity of network-based security controls that rely on standard, predictable web page behavior.
The historical precedent of data exposures tied to browser extensions also looms large in this discussion. The pattern of a handful of extensions inadvertently or deliberately enabling broad data collection from end users has appeared before, highlighting the vulnerability of users who rely on a large ecosystem of extensions to perform everyday tasks. Taken together with the current findings, the threat model paints a scenario in which a substantial portion of the browsing population could be unknowingly contributing to a data-collection operation that benefits paying clients with limited visibility into the scope of data being accessed or the specific sites involved. This combination of privacy risk and security risk intensifies the need for deeper scrutiny of how extensions are built, distributed, and governed across major browser platforms.
Beyond the technical mechanics, this threat model invites a broader discussion about how users perceive consent and control over their browsing environment. Even when extensions promise practical utility, the existence of an underlying data-sharing stream and a dynamic, remote server-driven workflow challenges the assumption that installing an extension is a simple act of enabling a feature. In this context, consent is not just a one-time checkbox at installation; it is an ongoing posture that requires ongoing visibility into what the extension is doing, what data it collects, and how that data is used. Without such transparency, end users are left with a difficult choice: accept a certain degree of opacity in exchange for service convenience, or withdraw from an ecosystem that increasingly relies on extensible, third-party code to deliver core functionality. This tension is not simply a technical issue; it is a core governance question about the future direction of browser ecosystems and the degree to which third-party developers should be entrusted with sensitive browsing capabilities.
Status updates and user-impact considerations: what has changed since discovery
In the wake of the initial findings, the ecosystem responded with a patchwork of updates and status changes across the affected extensions. A snapshot of the current landscape shows that within the Chrome ecosystem, 45 known extensions had been identified as incorporating the problematic library. Of these, 12 extensions have become inactive, signaling that they no longer perform the core data-access or monetization functions. Some of these extensions were removed from distribution due to malware concerns, while others proceeded with updates that removed the library from their codebase altogether. The net effect is a partial erasure of risk associated with Chrome users, but a residual risk persists due to older installations, cached components, or updates that have not yet been deployed in certain environments.
In the Edge ecosystem, 129 extensions were found to embed the library, with eight extensions currently marked as inactive. This attenuation again reflects a trend toward disengagement from the core library or a move away from the scope of the original malicious or risky behavior. In Firefox, 71 affected extensions showed two that are now inactive, with some updates also removing the library or eliminating the library’s dependencies. The pattern across all three major browsers indicates a broader cleanup, but the extent of the cleanup is uneven and depends on deployment cycles, user adoption, and the rate at which developers publish updates. The status updates underscore a critical point: even when a portion of the ecosystem is pruned and the most dangerous functionality is removed, a subset of extensions and their installed bases may continue to operate with the underlying library in place, or with residual interactions that reflect incomplete cleanup.
From a risk-management standpoint, the ongoing presence of the MellowTel library within active extensions is particularly concerning for users who rely on older copies of extensions or who operate in environments with slower update cadences. Enterprises that enforce strict change-control policies and rapid patching may still be vulnerable if unpatched extensions exist on a subset of machines or if corporate devices inadvertently sideload extensions from internal sources. Additionally, the dynamic nature of the library—whereby it can modify requests and responses and inject additional content into pages—means that even a seemingly benign extension could become a vector for unexpected, and potentially harmful, behavior if its trust assumptions are compromised or if the library receives updated instructions from a monetization partner.
The broader implications for users who are not enterprise-bound are equally meaningful. Even in consumer contexts, the fact that an extension can orchestrate a websocket connection to a remote server and coordinate the opening of hidden content across visited pages means that privacy and security protections are being exercised in ways that users may not anticipate. The practical reality is that many users do not routinely audit the exact sites with which their extensions interact, nor do they routinely review all network activity associated with extensions. The opacity of this process makes it harder for users to detect or verify that the extension is acting within ordinary, expected bounds. This is especially true for extensions that serve practical, everyday tasks such as bookmarking or volume control, which might be perceived as low-risk activities but are, in effect, part of a larger system that can be surreptitiously harnessed to perform data-collection or web-access actions on demand for a third party.
There is a clear implication for the way in which extensions are maintained and monitored. If a library can be embedded into a broad set of extensions with differing purposes, the risk surface expands significantly. The more extensions that rely on a single library to monetize or facilitate data access, the greater the chance that a change in the library, a vulnerability in the library, or a misconfiguration in a small subset of extensions can cascade across a broad portion of the browser ecosystem. This kind of cascading risk emphasizes the importance of robust, centralized vulnerability disclosure processes, more stringent vetting for libraries used by extensions, and ongoing monitoring that extends beyond the deployment of the extension itself to include its dependencies and the external services it may connect to.
A further takeaway from the status updates is the need for greater transparency around the follow-up actions taken by extension developers in light of these findings. Some extensions explicitly removed the library in subsequent updates; others reported malware removal as part of a broader cleanup strategy. Yet, the exact scope of what remains in place and how the remaining components operate is not uniformly documented in user-facing terms. For users who want to protect themselves, the absence of straightforward, accessible information about a given extension’s internal dependencies—the precise presence or absence of MellowTel or similar libraries—complicates the task of assessing risk. This underscores the value of improved, standardized disclosure practices within the browser ecosystem, such that users can more readily determine whether an extension they rely on continues to embed risky components, even if those components are not the primary feature of the extension.
In addition to the numerical status updates, researchers emphasize that a complete and comprehensive list of affected extensions still matters. The historical record shows that even when many extensions are removed or their risky components sanitized, there may be follow-on effects—such as extensions updating to reintegrate limited portions of the library under different names or with altered permissions. Hence, a careful, continued audit is essential to ensure that newly introduced or reintroduced capabilities do not re-create the same vulnerability profile. The broader community would benefit from a transparent, centralized catalog of known-risk extensions and their current status across major browsers, along with guidance on how users and IT teams can audit their endpoints for traces of the library or related data-sharing components.
Historical context and the broader industry response to browser-extension risks
The current case sits within a longer arc of browser-extension risk that has periodically resurfaced as the ecosystem grows in size and complexity. A notable predecessor involves a 2019 analysis that traced a large-scale extension operation that collected user data and shared it with a data analytics service that ultimately became defunct following public scrutiny. That episode highlighted how a combination of broad extension permissions, network interactions, and centralized data-access paradigms can yield pervasive data collection across millions of devices, often without clear, user-facing explanations. The parallel to the present discoveries underscores a recurring vulnerability in the way extensions are designed, deployed, and governed—namely, the tendency for monetization-centered architectures to push the envelope on privacy and security boundaries under the banner of utility and efficiency.
From a policy and platform perspective, the major browser vendors have repeatedly weighed in on how to regulate extension behaviors to mitigate such risks. The debate centers on how to balance the practical benefits of extensions—customized browsing enhancements, productivity boosts, and tailored user experiences—with the imperative to protect user privacy, preserve the integrity of security headers, and prevent covert data exfiltration. A key aspect of this regulatory tension concerns how to manage third-party libraries embedded within extensions. When a library has the power to alter network requests and responses or to inject content into pages, it effectively sits at the intersection of software security, privacy, and data governance. The risk is not only about the library itself but also about how it interacts with the websites a user visits, how it can be updated, and what safeguards exist to prevent abuse of its capabilities.
Within the industry, there has been a push toward more rigorous extension-review processes. This includes better vetting of libraries that extensions rely on, stricter controls over what permissions can be requested, and improved transparency regarding what data is collected and how it is used. In practice, this means that extension developers must disclose dependencies clearly, and platform providers must offer more robust auditing tools and risk-scoring frameworks to help users and administrators identify potentially risky combinations of libraries and extension functionalities. The broader conversation also includes questions about possible enhancements to Content Security Policy enforcement, improved isolation of extension code, and more resilient safeguarding of end-user sessions against unexpected header modifications or cross-site content injection.
Another dimension of the industry response involves enterprise-ready safeguards. Enterprises increasingly rely on central management of extensions—whitelisting, blacklisting, and controlled deployment—to minimize exposure to risky code. In some cases, organizations deploy additional security controls such as network-based monitoring of extension traffic, endpoint detection and response (EDR) tools that can identify unusual activity associated with browser extensions, and strict policies that limit which extensions can be installed or updated. This systematic approach is essential because even a handful of problematic extensions can create a disproportionate risk if they operate in a permissive environment or if a distributed network of user devices effectively acts as a swarm of data collectors for a paid client base.
From the perspective of developers and extension authors, the lessons are equally instructive. The episode emphasizes the importance of designing extensions that respect user autonomy and privacy, with secure, auditable data-handling practices. It also underscores the necessity of robust testing to ensure that library dependencies do not inadvertently erode security protections or create new, exploitable surfaces. The governance implications for software ecosystems that rely on open-source components further stress the need for clear licensing, responsible disclosure, and governance structures that can quickly identify, report, and remediate vulnerabilities associated with widely reused libraries. Taken together, these considerations form a roadmap for a healthier balance between enabling functional, revenue-generating extensions and safeguarding the fundamental protections users expect when they browse the web.
Best practices for users and organizations to mitigate risk
For users who want to minimize exposure to potentially risky extensions, several practical steps can be taken. First and foremost, exercise caution when installing extensions, particularly those that request broad permissions or that promise feature sets that appear tangential to the core tasks they perform. Users should review the permission requests in detail and consider whether the extension truly needs the wide-ranging capabilities it claims to require. If a library or dependency is not necessary for the extension’s stated purpose, it should raise a red flag. Second, maintain a habit of periodically auditing installed extensions, especially those that have not been updated recently or that originate from developers without a long track record of security-focused releases. When in doubt, disable or uninstall extensions that you do not actively use, and prefer extensions from reputable developers who follow best practices around privacy-by-design, minimal permissions, and transparent data-handling policies.
For organizations, the risk landscape requires a more formal approach. IT and security teams should implement centralized extension management that includes a vetted catalog of approved extensions, rigorous version-control practices, and a continuous monitoring process for extension behavior. Network and endpoint security controls should be augmented with telemetry that can detect unusual patterns in browser activity, such as unexpected data transmissions, repeated or anomalous websocket connections, or the injection of content into web pages that is not consistent with normal browsing flows. Enterprises should also consider employing segmentation and isolation strategies for user devices to limit the potential blast radius if a compromised extension is detected. Regular security assessments must include checks for legacy extensions or outdated components that could still exercise harmful behavior due to older dependencies, as well as a clear plan for rapid remediation in the event that a library or extension is found to be misconfigured or malicious.
From a developer perspective, responsible and privacy-conscious practices are essential. Developers should avoid embedding libraries that enable broad, covert data access unless the extension’s purpose clearly necessitates such capabilities and users have explicit, granular consent. They should implement robust security controls that deter the injection of external content or the manipulation of web requests in ways that could undermine site integrity. A transparent data-use policy and a straightforward mechanism for users to opt out of non-essential data-sharing activities are critical. In addition, developers should participate in coordinated vulnerability disclosure programs and maintain up-to-date documentation that helps users and security professionals understand what data is collected, how it is used, and what protections are in place to prevent abuse. When possible, using sandboxed or isolated execution environments for extension code can help limit the potential for cross-origin data leakage or runtime conflicts with other extensions and site content.
At the policy level, ongoing discussion among regulators, platform operators, and security researchers should continue to emphasize user protection and the integrity of the browsing experience. Policymakers could consider enhanced transparency requirements around extension dependencies, standardized risk disclosures for third-party libraries, and more rigorous mechanisms for auditing extension behavior in real-world usage. The goal of these policy developments would be to create a safer ecosystem where the practical benefits of extensions can be enjoyed without compromising user privacy or network safety. The ultimate objective is to ensure that users understand what data is being collected, when it is collected, and who has access to it, and that there are reliable safeguards to prevent any organization from turning millions of devices into an unconsented data collection operation for commercial profit.
The road ahead: future implications, ongoing vigilance, and a measured conclusion
Looking forward, the implications of this discovery extend beyond the immediate set of extensions and the specific monetization library at issue. The incident underscores that the terrain of browser extensions, privacy, and security is a dynamic, evolving frontier where small, widely-deployed components can have outsized effects on user safety and data integrity. The core questions center on how platform vendors, security researchers, developers, and users can maintain the delicate balance between enabling useful extensions and preserving a trustworthy browsing environment. The presence of a data-monetization model that leverages distributed extension networks to fulfill third-party requests invites ongoing scrutiny of how extensions are designed, deployed, and audited, and how consent and transparency can be improved so that users retain meaningful control over their own data.
Technological measures, policy reform, and industry collaboration will all play roles in shaping the next steps. On the technology side, strengthening guardrails around dynamic web-request modification, optimizing the isolation of extension code, and improving the visibility of extension behavior to users could help reduce the risk of covert data access and content injection. On the policy side, developing clearer guidelines for third-party libraries embedded in extensions and establishing standardized disclosures about data access and usage could empower users to make more informed decisions. Industry collaboration, including coordinated vulnerability disclosure and shared threat intelligence across browser vendors and security researchers, will be crucial to identifying and mitigating new patterns of abuse as they emerge in this rapidly evolving space.
In sum, the discovery of these nearly 1 million devices turned into covert browsing agents via a shared library embedded in hundreds of extensions exposes a multi-faceted risk landscape. While some extensions have partially or fully removed the problematic library, the fact remains that a sizable portion of the ecosystem has developed around a monetization model that can enable aggressive data access through user devices. The situation demands a careful, ongoing assessment by users, IT teams, developers, and platform operators to ensure that privacy protections are robust, that users are informed and able to consent meaningfully, and that the integrity of the web browsing experience remains resilient against the evolving tactics of monetization-driven extension ecosystems.
Conclusion
A complex web of browser extensions contains the MellowTel-js library, enabling a paid network of data-access and page-access activities that monetize user traffic. The operation hinges on a mix of websocket telemetry, hidden iframe content loading, and dynamic manipulation of security headers, creating privacy and security risks for individual users and enterprise networks alike. While some extensions have reduced risk by removing the library or becoming inactive, others remain in circulation, underscoring the need for vigilance, transparency, and stronger safeguards across browser ecosystems. Users should scrutinize extensions closely, limit permissions, and remain aware of the broader data-sharing context in which these tools operate. Enterprises must bolster their monitoring and governance to prevent unvetted code from undermining security postures, while developers should embrace privacy-by-design principles and transparent data practices to restore trust in an ecosystem that must balance utility with the fundamental protections users expect when they browse the web.
