WordPress exploits – A review of what’s going on

As you may or may not know I setup http://wpsecure.net/ as a hobby a few years ago to track exploits for plugins hosted on wordpress.org. The main reason I created the site was twofold, to alleviate some of the finger-pointing directed at WordPress core, and to educate users and plugin authors since most vulnerabilities are easy to correct using proper WordPress or PHP/JS coding practises.

License Plate SQL Injection Attack

  • The stats are gathered from wordpress.org plugins, no themes or plugins from other sites are included.
  • Plugins that were removed from wordpress.org prior to information release were not included (several)
  • The reported period is from Jan 1, 2011 – August 1st -2013, and includes approximately 420 plugins.
  • Approximately 14 plugins per month are reported on average.
  • Millions of users have downloaded these plugins (sorry I don’t have the exact stats, but it’s millions).
  • All exploits included a valid POC.

It is really important to note these stats should not give anyone a sense of quantity or any accurate number in terms of how many plugins hosted on .org have actual exploits. The way plugin exploits are reported via security bulletins are sparse at best and often a result of security audits by large organizations that can afford to do so . For example you might not see any exploits for a month, then all of a sudden 25 show up in one day due to a 3rd party audit. No one seems to be doing any theme auditing, meaning themes rarely if ever show up on security lists, another signal that most audits are done by larger organizations (and in some cases governments) who do not use public themes. Also since I do this as a hobby the quantity and stats are not 100% accurate, but should still provide an overall grasp of the subject.

The fact that the exploits typically come in waves show that the actual number of vulnerable plugins is significantly higher than reported, the reason being, websites are audited with a limited amount of plugins and not plugins en masse. It’s also important to note that exploit information is traded as a commodity in some circles before released, if ever.

What the stats show are the types of exploits occurring, which can be broken down into 3 main groups, the first 2 being panic inducing,  and the latter being the most popular method and ranging from “not a huge deal”  to significantly bad for you and your users, depending on the case.


Results including the timthumb.php exploit skewed the results for   “File inclusion” %:


It’s a bit surprising the SQL injection and File Inclusion are so high considering they are so damaging, I expected those numbers to be lower and XSS to be more around 65-75%. It is possible lots of XSS goes unreported due to being thought of as “insignificant”, or due to how vast auditing XSS specifics can be compared to the relative ease of finding file inclusion issues. I did not include CSRF in the stats since it amounted to below 3% and was usually bundled with an XSS vector.

Compared to OSBVB’s stats which track a much larger segment (currently about 90k exploits), you can see File Inclusion in the industry is much lower than found in WordPress.

The good news in the chart below is the continued downtrend of File Inclusion and SQL Injection types, mainly due to developers being more educated about security and frameworks providing default sanitization and validation techniques. This downward trend is also most likely mimicked in WordPress, though I do not have the stats for it, let’s hope so.



Its really important that end users know the vast majority of plugins that have security problems on wordpress.org are patched within 1-3 weeks of disclosure (non -public), and most unpatched ones are removed quickly by the wordpress.org team. That is why it’s crucial to update your plugins.

Themes are a huge grey area since many themes come coupled with lots of  “code”, the barrier of entry for theme developers in terms of security and PHP/JS knowledge is typically lower , and many people using 3rd party theme services as opposed to wordpress.org which has a review process.

Another important tidbit is that theme authors should be very wary of including 3rd party code bundles, for example two scripts, timbthumb.php and a 3rd party flash video player,  accounted for at least 40 exploits on wordpress.org. From a casual glance at sites like themeforest it is easy to see that the majority of themes are bundling 3rd party scripts, most likely with no oversight.


Some links for developers on how to write better plugins..and themes.

  1. http://codex.wordpress.org/Data_Validation
  2. http://codex.wordpress.org/Validating_Sanitizing_and_Escaping_User_Data
  3. http://wordpress.tv/?s=security
  4.  https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet (XSS Cheat Sheet)

For exploit POC’s are compiled via various security lists including:


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s