Notifications
Clear all
Topic starter
02/08/2026 11:23 am
TL;DR: A Chrome extension with 11 million installs, all-site permissions, and remotely controlled scriptlets can be made to inject code into any page with one server-side change, according to Island. The risk is not a proven payload but a trusted browser control plane that can outlive user expectations and bypass normal store-review assumptions.
NHIMG editorial — based on content published by Island: BadBlocker: 11 Million Users, One Server Call Away from Compromise
By the numbers:
- Adblock for YouTube has over 11 million installs, 374,000 reviews, and a 4.4-star rating.
- It ranks #31 overall in the Chrome Web Store.
Questions worth separating out
Q: What breaks when a browser extension can fetch remote rules that control page injection?
A: The trust boundary breaks because the extension is no longer a fixed add-on.
Q: Why do all-site browser permissions create risk for enterprise identity sessions?
A: All-site permissions let an extension operate across webmail, SaaS, admin tools, and internal applications, which means it can intersect with SSO-backed sessions.
Q: What do security teams get wrong about trusted browser extensions?
A: They often assume the store listing is the control, when the real control is the extension’s runtime behaviour.
Practitioner guidance
- Audit extension host permissions against declared purpose Inventory all browser extensions and compare their effective host permissions with their stated function.
- Flag remote rule delivery in browser add-ons Identify extensions that fetch configuration from external servers and use that configuration to control page behaviour, scriptlets, or injection logic.
- Include browser extensions in identity risk reviews Add extension review to controls around SSO, SaaS access, and privileged web sessions.
What's in the full article
Island's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step proof-of-concept flow showing how the extension can move from YouTube to Salesforce under an authenticated session
- Code excerpts for the remote rules fetch and MAIN-world injection path that demonstrate how server-side control changes runtime behaviour
- Historical extension and infrastructure evidence, including ownership changes and related extension removals tied to the same ecosystem
- Appendix indicators of compromise and the specific extension IDs, domains, and historical endpoints referenced in the research
👉 Read Island's analysis of the BadBlocker browser extension risk →
Browser extensions with all-site access are a governance gap teams miss?
Explore further
02/08/2026 12:41 pm
Browser extension governance is now identity governance by another name. Extensions with broad host permissions operate inside the same authenticated workspaces that IAM teams are trying to protect. When those extensions can be directed by remote configuration, the control problem shifts from install-time trust to runtime authority, which is where conventional app review falls short. Practitioners should treat browser extensions as privileged runtime components, not user conveniences.
A question worth separating out:
Q: Who is accountable when a browser extension abuses authenticated work sessions?
A: Accountability usually sits with the organisation that allows the extension into managed browsers, plus the teams that own endpoint policy and identity governance. When an extension can act inside authenticated sessions, the issue is not just a browser problem. It is a control failure across access, session, and software governance.
👉 Read our full editorial: 11 million browser installs can turn one server change into compromise
