Adblock for YouTube: 11 Million Installs and a Serious Security Flaw to Fix

More than 10 million installs, a special badge on the Chrome Web Store, and a code-injection feature ready to be remotely activated. That is the picture painted by Island researchers about a Chrome extension you may be using right now: Adblock for YouTube. Although it is effective at blocking ads, it also includes the ability to execute arbitrary JavaScript on any website. Here is what we know.

A YouTube extension that runs on every site

The extension in question is called Adblock for YouTube (ID cmedhionkhpnakcndndgjdbohmhepckk). Available on the Chrome Web Store since 2014, it claims more than 10 million installs, 374,000 reviews, a 4.4 out of 5 rating, and a Featured badge. In short, a reassuring profile that makes you want to install this extension without a second thought to block ads on YouTube.

However, a report published by Island researchers highlights several concerning points.

First of all, why would an extension supposedly limited to YouTube request the host_permissions: ["<all_urls>"] permission? In other words, why does it ask for access to every site you visit: webmail, online banking, SaaS applications, admin consoles, internal tools?

At the code level, there is a kind of safeguard in place so the extension checks for the presence of youtube.com in the URL before any injection. But this check validates neither the host name nor the frame origin: it simply looks for the string youtube.com anywhere in the URL. That is not trivial, because it means the string is also detected in parameters: banque.example.com/search?q=youtube.com passes the filter.

A dormant code injection capability

Every 24 hours, the extension retrieves its configuration from a remote server (api.adblock-for-youtube.com/api/v2/rules). The response contains the usual blocking rules, but also a scripletsRules field. Through this mechanism, the server can specify which scriptlets to run and with which arguments. One of them, trusted-create-element, makes it possible to create a <script> element whose content is provided directly by the server, then executed in the page context with access to the DOM, sessions, forms, and user actions.

That means this extension, and more specifically this capability, could be used to:

• Read content on the pages being visited,
• Steal sensitive data (credentials, displayed content),
• Perform actions on behalf of the user, including on authenticated services.

Most importantly, the problematic part is that it is invisible since it is driven directly from the server: all of this can be triggered without updating the extension, without a new Chrome Web Store review, and without the slightest visible signal for the user.

"The capability is dormant, not absent. Activating it requires only one server-side change.", the Island researchers explain.

To validate their discovery, the research team built a PoC in which a script served from YouTube ends up being injected into an authenticated Salesforce session and exfiltrating account data to a test server.

"To validate the execution path, we set up a controlled proof of concept using a local simulation server. The server responded to the extension's normal API request for rules, but the extension itself was not modified: same package, same permissions, same URL check, same scriptlets library, same injection logic.", we can read.

A troubling history and the publisher's response

According to Island, the extension changed owners around 2018 and was heavily rewritten, a period from which it went from a few hundred thousand to more than 10 million users. Its older versions included the Unistream ad injection SDK, flagged by Bitdefender and removed in June 2024.

Most importantly, the extension is linked to several "sister extensions" removed from the Chrome Web Store for malware:

• Adblock for Chrome (ID onomjaelhagjjojbkcafidnepbfkpnee) ;
• Adblock for You (ID ogcaehilgakehloljjmajoempaflmdci) ;
• AdBlock Suite (ID gekoepiplklhniacchbbgbhilidiojmb), removed in September 2023.

After the report was published, AdBlock Ltd founder Mathias Rochus contacted The Hacker News to give his side of the story. According to him, the extension has never used this capability and never will.

More importantly, he seems determined to fix the issue through an extension update that should include two changes:

• The page check will now validate the YouTube host name instead of looking for the string youtube.com anywhere in the URL,
• The server configuration will no longer be able to create or inject executable script into the page.

Mathias Rochus also says that the scriptlets highlighted in the report, including trusted-create-element, are not code written by his company. According to him, they come from AdGuard's open source scriptlets library, used by mainstream ad blockers. In any case, it is essential to close this door: imagine for a moment if the server contacted by this extension were compromised....

This case joins a series of recent campaigns documented on IT-Connect, from popular Chrome extensions that spy on AI conversations, to the GhostPoster campaign and its 17 malicious extensions, and the ClaudeBleed flaw in the "Claude in Chrome" extension. On the defense side, companies can regain control of these installations by relying on the customizable Chrome Web Store for organizations, which makes it possible to allow only extensions approved by IT.

Florian Burnel Co-founder of IT-Connect

Systems and network engineer, co-founder of IT-Connect and Microsoft MVP "Cloud and Datacenter Management". I'd like to share my experience and discoveries through my articles. I'm a generalist with a particular interest in Microsoft solutions and scripting. Enjoy your reading.

See Full Bio