- Researchers at amibeingpwned.com say 37 of 60 OffiDocs Chrome extensions currently send the full URLs users visit to servers, with no explicit user consent.
- 57 of the 60 carry a Featured or Established Publisher badge, and the 60 together exceed 2.3 million users. Researchers say that makes them look safe.
- Check which extensions run in your managed browsers, and test their network behavior rather than relying on badges or permission scores.
A badge is not a background check
To the average user or colleague, a Featured or Established Publisher badge makes an extension look safe. A new report shows how far that look can mislead.
Researchers at amibeingpwned.com describe a campaign of 60 Chrome extensions tied to OffiDocs, spread across four publisher accounts. Of the 60, 17 carry the Featured badge and 40 the Established Publisher badge. That is 57 of the 60 with a badge. The researchers say the 60 together exceed 2.3 million users and 5,000 ratings.
The researchers say 37 of the 60 currently collect the full address of every page a user visits and send it to the publisher's servers. Most are ordinary workplace utilities for editing documents, spreadsheets, slides and PDFs. The report includes no response from OffiDocs, and these are the researchers' findings.
How the collection works
In the 37 extensions that collect URLs, each writes the visited URL into a request to the publisher's server. The URL is hex-encoded, meaning it is rewritten as a string of numbers and letters. A request also carries a user ID created at install. The researchers decoded one example back to a Google search address.
The VPNOnline extension works differently. It sends only URLs that match a keyword list, as the next section explains.
That encoding matters. The researchers say Chrome Web Store review uses basic matching that does not flag hex-encoded URLs. They also say data loss prevention tools, which watch for sensitive data leaving a company, will not flag it either.
The server can also act on the user. In many of the extensions, a reply containing "302" makes the extension call chrome.tabs.update(). That replaces the page the user was viewing with a page on redcoolmedia.net or runapps.org. The researchers say the server decides this per user and per URL.
The free VPN shows the pattern most clearly
The researchers single out "VPNOnline", which has 20,000 users. Its extension downloads a keyword list from onworks.net every hour. Any URL containing a keyword is hex-encoded and sent back with the user ID.
The list at the time of writing was exe;msi;tar;iso;ama. The first four mostly catch file downloads. The researchers note that "ama" also matches every amazon.com page. Because the list sits on the server, they say it can change what is collected without a new submission to store review.
The researchers also dispute the privacy claim. They say the extension takes its servers from a public file listing 8 plain HTTP proxies on rented Contabo servers, all sharing one published username and password. HTTPS sites stay encrypted end to end. But anyone on the user's network can see which sites are visited, and the proxy operator sees every host. A second RunApps VPN, OnVPN, has another 2,000 users.
Where the data ends up is not known
The privacy policies vary. The researchers say OffiDocs' policy describes URL collection as a way to "scan" for editable files. It then says aggregate or de-identified data "may" be shared with unrelated third parties, without saying which data or how it is de-identified. They say RunApps' policy does not mention collecting every URL at all.
OffiDocs' terms of service reference the Bright SDK from Bright Data. The researchers suspect the data may end up there. They add that the SDK is not embedded in the extensions, so this is a suspicion, not a finding.
URLs can hold more than a page name. The researchers point to legacy OAuth flows that can leak tokens, magic sign-in links and DocuSign documents.
The lesson: review checks the door, not the room
This is WebPulse's reading of the report. Store review inspects a package at one moment. In the behavior described here, the decisions sit on the publisher's server: which URLs to collect, and when to redirect a tab. A reviewer cannot inspect that in advance.
That makes an extension closer to a standing sensor inside every employee's browser than to a one-off software install. It sees every page the employee opens. The right question for an organisation is not "was it approved?" but "what does it do now, and who can change that?"
Questions to put to your team
First, ask for an inventory of extensions in managed browsers. Check for the four publisher accounts the researchers name: officeonlinesystems, RedcoolMedia, ApkOnline android online and RunApps.
Second, ask whether you allow extensions by approved list or by badge. The researchers say 17 of these carry Featured, so a badge-based policy would pass them.
Third, ask how your tools assess extensions. The researchers say permission and heuristic scoring is inadequate, and that even tools claiming deep code analysis missed most or all of these. Ask for network-behavior testing.
Fourth, set a policy on free VPN extensions. Fifth, find which staff use web apps that put tokens or sign-in links in URLs.
One caveat: the researchers offer an extension-scanning tool and invite readers to use it. They say the report rests on an automated pipeline plus manual sampling. Weigh their advice accordingly, and verify in your own environment.
A badge tells you who passed review once. It does not tell you what the server asks the extension to do next.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: amibeingpwned.com.
