Recently there has been a fair amount of coverage of popular Chrome extensions being modified to include malicious code after the login credentials used to control them in the Chrome Web Store had been compromised through phishing. In the past extensions have been purchased and then malicious code added to them as well. There is no reason that the same thing can’t happen with WordPress plugins and recent similar situation with the plugin Display Widgets shows that the people on the WordPress side of things are not currently up to task of handling this type of situation properly. Unfortunately, this isn’t at all surprising because elements of the failure with this situation are things that we have been seeing and discussing for some time.
The requesting developer does not have the experience we feel the plugin requires
The requested plugin is deemed high-risk
The existing developer is a company or legal entity who owns the trademark
The requesting developer has had multiple guideline infractions
If you were to takeover a plugin directly from the developer there is no restriction. In this case the account of the developer on wordpress.org was created the same day they made their first change to the plugin after taking ownership.
A Red Flag
The first release from the new developer sounds highly problematic. Here is how it is described by David Law (the file mentioned is no longer available for download, so we can’t independently confirm this):
What it added was an automated download of another plugin (a geolocation widget: was over 50MB in size!) from a private server!
Automatically installing code from a private server is against the WordPress plugin repository rules.
The new code also connected to another server to track visitors data including:
IP Address (can potentially track you to your street address) Webpage Visited (URL of the webpages a visitor visited) Site URL (the URL of the WordPress site the Display Widgets plugin is installed on) User Agent (which browser the visitors uses etc…)
Automatically tracking user data etc… without the permission of the site owner is against the WordPress plugin repository rules.
David then reported this and action was taken:
I reported the infringements to the plugin repository, simply email them via email@example.com and explain what’s you think is wrong.
Version 2.6.0 was removed from the plugin repository. If you are using version 2.6.0 of the Display Widgets Plugin on your site, remove it NOW.
The plugin repository are very understanding, a week or so later the developer released a new version (v2.6.1).
Spam Posts Added
Considering what happened there you would hope the people running the Plugin Directory would have carefully checked the new version of the plugin, but they don’t seem to have. That isn’t all that surprising to us because in the past we have noted that they have returned plugins to the directory despite the vulnerability that caused them to be removed having not been fixed. Making sure that a known vulnerability has been fixed is much easier than making sure there isn’t any malicious code in a plugin, so if you fail at that former, the latter isn’t surprising. Unfortunately we have seen zero interest from the WordPress side to fix this or many of the other issues we have seen with their activity.
In version 2.6.1 there was code added that should have raised the suspicions even without fully understanding what was going on in totality. In particular was the new function check_query_string() in the new file geolocation.php:
At first glance it isn’t clear what this code might be doing, but it does seem odd. It seems to us that simply trying to find out what it did from the developer would have lead to the plugin not being restored with that code in it.
What the code looks to be doing is generating a WordPress post and saving it as a WordPress option (setting), which also seems odd.
Where that setting is used is with the function dynamic_page(). That function runs when a set of posts is being generated: