When it comes to the discussion of WordPress security one thing that stands out for us is how much of what is being said seems to be, at best, not backed by factual information and in too many cases seems to be backed by outright falsehoods. So that makes gathering and analyzing data on security issues a much needed activity.

Recently we spotted what looked to be an attempt to exploit a vulnerability in the plugin WP Mobile Detector, a plugin with 10,000+ active installs according to wordpress.org, and we quickly found an arbitrary file upload vulnerability in the relevant file in the plugin, which turned out the be what was being exploited. After the vulnerability received a fair amount of press coverage we saw more requests that looked to be part of attempting to exploit the plugin. Now that it has been three weeks since this started we thought it would be a good time to take a closer look to see what impact that actually had.

First here is a timeline of what happened:

• 5/27/2016 – Someone probed one of our websites looking for the existence of a file in the plugin, which is usually an indication they are looking to exploit a vulnerability in it.
• 5/29/2016 – We notified the developer of the plugin of the vulnerability we discovered.
• 5/31/2016 – We disclosed the existence of the vulnerability on our blog, along side of that we added it to our data set for our service and added it to the free data that comes with the companion Plugin Vulnerabilities plugin.
• 5/31/2016 – We notified wordpress.org Plugin Directory of the vulnerability.
• 5/31/2016 – The plugin is removed from the Plugin Directory.
• 6/2/2016 – The vulnerability receives press coverage.
• 6/2/2016 – Version 3.6 of the plugin is released, which fixes the vulnerability.

Below is a chart that shows the number of IP addresses that made request for URLs in the plugin’s directory on the website by day(there were no requests after June 8):

You can see that after the first request there were no additional requests until the day that the vulnerability was covered by the press. That shows that there is at least a correlation between the two and probably indicates that that more coverage of a vulnerability leads to additional exploitation attempts.

Since you it would be hard to control what coverage a vulnerability receives, trying to do that doesn’t seem to be a real good avenue for improving this type of situation. Instead this points to the impact that speeding up the process of getting vulnerabilities fixed could have. It took the developer four days and having the vulnerability removed from the Plugin Directory to get it fixed. It should not have taken any where near that long to fix it. That might point to a need for the Plugin Directory to take a more proactive role in fixing vulnerabilities when they are already being exploited prior to being fixed (which we have been seeing quite a bit of lately). (We would happy to help them putting together those fixes.)

The stats page for the plugin on WordPress.org shows that once the new version was released there was quick uptake (the big spike occurred on June 3):

For five of the six days after June 2 there were requests and then the requests stopped, probably due to limited number of websites still vulnerable at that point (many websites using the plugin were never vulnerable due to the vulnerability requiring a PHP option known to introduce security risk be enabled to be exploitable).

Total Request by Day

Below is a chart of the total request for URLs in the plugin’s directory made each day on the website:

URLs Requested

Below is a breakdown of the URLs that were requested in the plugin’s directory on the website and how many times each was requested.

URL	Requests
/wp-content/plugins/wp-mobile-detector/admin/css/style.css	12
/wp-content/plugins/wp-mobile-detector/resize.php	12
/wp-content/plugins/wp-mobile-detector/js/jMobile.min.js	5
/wp-content/plugins/wp-mobile-detector/readme.txt	4
/wp-content/plugins/wp-mobile-detector/	2
/wp-content/plugins/wp-mobile-detector/cache/shun.php	2
/wp-content/plugins/wp-mobile-detector/resize.php?src=http://www.nipponclub.org/wp-content/themes/twentythirteen/inc/aaa/shun.php	2
/wp-content/plugins/wp-mobile-detector/cache/css.php	1