- Researchers at malext.io report that SelectorsHub 5.8.5 opens server-chosen ad tabs and labels some as '100% Safe', without disclosing this in its Chrome Web Store listing.
- The ad list lives on a remote server, so it can change without an extension update and outside the code a store reviews.
- Teams should check which extensions staff run, treat store listings as claims to verify, and watch the extension's outbound traffic.
A browser extension passes review once. The server behind it can change without a new version. That gap is the real subject of a malext.io report on SelectorsHub, a selector tool for QA and test automation engineers.
What the researchers found
Malext.io tested SelectorsHub 5.8.5 and published its findings on October 5. The researchers found a built-in ad system. The extension's store page says nothing about it.
While it runs, the extension downloads web addresses from selectorshub[.]info. It opens them in background tabs. On install and on update, those tabs open with no overlay and no user action.
In the side panel and the DevTools panel, a five-second overlay comes first. It calls the link a "community link" and states "100% Safe, No Spam, No Malware". The destinations the researchers observed were paid advertisements.
How it works
The design is simple. A script called background.js asks the server for a list named link-ads. It opens every address that comes back. The uninstall address arrives in the same reply.
A second script, update.js, runs inside the panels. The server decides how often it fires. At review time, the setting was every 2 days for the slug SH.
The researchers saw three different ad rotations from this one mechanism. A later request returned empty install and update lists. So the destination can change, or vanish, with no new version.
That matters to a manager. A reviewer reading the code sees a request and a tab opening. The ads are not in the code.
Cookies and data the listing does not mention
The package asks for the cookies permission. It calls cookies.getAll({}), which reads every cookie in the browser. The researchers trace this to one goal. The code wants a single cookie that belongs to the extension, named selectorshub authentication.
The extension also pings shub.selectorshub.info once a day. The researchers call this a counter ping, not a browsing report. Ad-click events go to link/track and to shubads.testcasehub.net/analytics/ads/track.
On the store page, the developer's privacy statement says user data is neither collected nor used. The researchers conclude that the extension does more than build selectors. They say it should describe that accurately.
A risk that is not proven
The extension has an AI feature that repairs selectors. Whatever selector a user feeds into it leaves the browser and lands on a remote host, shubads.testcasehub[.]net, under the route /gpt/fixpath.
In the DevTools panel, the extension reads the reply. If it is JSON with a fix field, that value goes into inspectedWindow.eval(). That call runs text as code in the inspected page.
The researchers call this a confirmed code path. They say exploitation is not established. In testing, the endpoint sent a redirect to blomehairdryers[.]com, an Indonesian gambling site. That reply was HTML, so parsing failed and the local fixer ran. The gambling page never reached the eval call.
The button that triggers this feature is parked off-screen in the 5.8.5 package. Nobody has yet been named as running the redirect.
The lesson: approval is a snapshot, behaviour is a feed
This report shows where trust has moved. Store review inspects a package at one moment. The behaviour that matters here arrives later, from a server the reviewer does not control.
Think of an inspector who signs off a shop lobby while the tenant swaps the signs every week. The inspection was real. It just does not cover what visitors see.
The researchers spell out the consequence. A server change reaches every installation at once. It could be a business decision or the result of a compromise. A QA engineer who installed a selector helper sees pages a stranger's server picked, with a safety claim attached in the panels.
Two caveats apply. Google has issued no formal finding. These are the researchers' own policy objections. Their adware label rests on their analysis of the 5.8.5 package.
What to ask your team
Start with inventory. Which extensions run on engineering and QA machines? Who approved each one?
Next, treat store listings as claims, not evidence. If an extension reads cookies or calls remote servers, compare that with its privacy statement.
Then check traffic. Search proxy or DNS logs for selectorshub[.]info and shubads.testcasehub[.]net. Ask whether policy can allow only approved extensions on managed browsers.
Finally, ask the vendor for a written explanation of the ad system, the cookie read and the fix endpoint.
A clean review tells you what an extension was on the day it was checked. The server tells you what it is today.
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: malext.io.
