I wish I wouldn’t have to post content like this, but it seems everything has a first time. Details about circumstances, next steps and lots of apologizes in this article.
Two reports arrived from two sources. I would like to say thank you for everyone involved in discovery and investigation.
#1: XSS Vulnerability if Cloudflare country code option enabled
In GTM4WP plugin options, under Basic data, the Weather & geo data section includes an option called Cloudflare country code. This option was introduced in v1.10. It is turned off by default.
Users of Cloudflare can use this option to have data about the visitors country code that is being passed through a HTTP header by Cloudflare. The data was not properly escaped thus could be used by attackers to inject code into the opened website using prepared links.
Thanks Guillaume Fortier for discovering.
#2 XSS Vulnerability if adding site search into data layer
In GTM4WP plugin options, under Basic data, Search tab includes an option called Search data. The vulnerability was only working if both this and the already deprecated Google Ads remarketing option on the Basic data / Google Ads tab was enabled. Both options were turned of by default on new installations of GTM4WP.
Using prepared links to a website using GTM4WP and the mentioned features, attackers could inject and run code in the browser of the user.
To fix this issue, I removed the deprecated Google Ads remarketing option in v1.15.1. This removal was already planned but only later this year.
Important: this does not affect the updated Google Ads dynamic remarketing feature in the WooCommerce integration. Dynamic remarketing data is still present in the data layer. The removed feature mirrored the content of the data layer into a JavaScript variable google_tag_params that was automatically read by the older version of the Google Ads remarketing tag. Since the updated remarketing tag does not use this directly and especially through Google Tag Manager you can setup variables sent to Google Ads manually, this feature removal should not harm your existing GTM implementation.
Original report by not_stoppable. Root cause analysis by Cory Buecker. Thanks for everyone!
I sincerely apologize…
Though as you may see, both vulnerabilities are bound to features that might be used in fewer cases, that does not mean I want to trivialize the issues. GTM4WP is now used on thousands of websites. Each and every vulnerability is a risk for them therefore I need to make sure such cases do not happen in the future.
I sincerely apologize from everyone even if not using the mentioned features. I really hope the trust you have towards this project did not harm that much and I can gain back every peace of that trust if lost at any level.
How to achieve this?
The next version of GTM4WP will not include new features but I will go through every line of code to make sure every data is properly encoded and safe to use. This also includes better code formatting and more code comments so that professionals trying to discover such cases can better understand everything in the code.