Adblock Plus filter lists may execute arbitrary code in web pages · Armin Sebastian


Get real time updates directly on you device, subscribe now.

A new version of Adblock Plus was released on July 17, 2018. Version 3.2 introduced a new filter option for rewriting requests. A day later AdBlock followed suit and released support for the new filter option. uBlock, being owned by AdBlock, also implemented the feature.

Under certain conditions the $rewrite filter option enables filter list maintainers to inject arbitrary code in web pages.

The affected extensions have more than 100 million active users, and the feature is trivial to exploit in order to attack any sufficiently complex web service, including Google services, while attacks are difficult to detect and are deployable in all major browsers.

Considering the nature and implications of the uncovered vulnerabilities, and given that filter lists have been employed in the past for politically motivated attacks, details of the exploit chain are publicly disclosed to ensure the fastest possible propagation of upcoming mitigations in the affected browser extensions and web services.


The $rewrite filter option is used by some ad blockers to remove tracking data and block ads by redirecting requests. The option allows rewrites only within the same origin, and requests of SCRIPT, SUBDOCUMENT, OBJECT and OBJECT_SUBREQUEST types are not processed.

However, web services can be exploited with the help of this filter option when they use XMLHttpRequest or Fetch to download code snippets for execution, while allowing requests to arbitrary origins and hosting a server-side open redirect.

Extensions periodically update filters at intervals determined by filter list operators. Attacks are difficult to detect because the operator may set a short expiration time for the malicious filter list, which is then replaced with a benign one. Organizations and individuals may be targeted based on the IP addresses from which the updates are requested.

The following criteria must be met for a web service to be exploitable using this method:

  1. The page must load a JS string using XMLHttpRequest or Fetch and execute the returned code
  2. The page must not restrict origins from which it can fetch using Content Security Policy directives, or it must not validate the final request URL before executing the downloaded code
  3. The origin of the fetched code must have a server-side open redirect or it must host arbitrary user content

Filter list operators may deliver a rule update such as this:


The above rule redirects the target request to Google’s I’m Feeling Lucky search service, which then redirects to a page with the payload: alert(document.domain).

Steps for running arbitrary code on Google Maps:

  1. Install either Adblock Plus, AdBlock or uBlock in a new browser profile
  2. Visit the options of the extension and add the example filter list, this step is meant to simulate a malicious update to a default filter list
  3. Navigate to Google Maps
  4. An alert with “” should pop up after a couple of seconds

Gmail and Google Images also meet the listed conditions to be exploitable.

Google has been notified about the exploit, but the report was closed as “Intended Behavior”, since they consider the potential security issue to be present solely in the mentioned browser extensions. This is an unfortunate conclusion, because the exploit is composed of a set of browser extension and web service vulnerabilities that have been chained together.

Please note that the vulnerability is not limited to Google services, other web services could be affected as well.


The exploit can be mitigated in the affected web services by whitelisting known origins using the connect-src CSP header, or by eliminating server-side open redirects.

Ad blocking extensions should consider dropping support for the $rewrite filter option. It’s always possible to abuse the feature to some degree, even if only images or style sheets are allowed to be redirected.

Users may also switch to uBlock Origin. It does not support the $rewrite filter option and it is not vulnerable to the described attack.

This blog and my open source projects
are made possible thanks to the support of awesome backers.
If you’d like to join them, please consider contributing with
Patreon, PayPal or


Get real time updates directly on you device, subscribe now.