Reflecting On Recent WordPress Plugin Vulnerabilities


Hello again!

Right before we published our Protect Your WordPress Sites from Attacks post, a vulnerability was found in WordPress SEO that was patched and pushed out as an auto update to all sites that include it. For the purposes of that post, I did not go into very much detail regarding what the issue was, but I’m here to do that now.


The issue was a blind SQL injection; the full report can be found here. Without getting into the entire technical details of WHY this works, the way someone could harm your site is by sending you a carefully crafted URL to your own admin dashboard that had SQL embedded in it. The reason this worked was WordPress SEO was taking URL parameters and using them right inside a SQL query without sufficiently sanitizing them.

The semi-interesting thing that happened after this vulnerability was patched was a flurry of other plugins releasing their own security updates–including WooCommerce and Pods. WooCommerce had a SQL injection vulnerability of its own reported by WordFence, while Pods, in response to the WP SEO issue, started a review of their own codebase for similar security issues.

While many of these plugins had updates that fixed these little security issues pushed out, the severity of these was really not that high according to a report by Sucuri.

This is all good information, but where are you going with this?

To give you an idea of the scope of how many sites would be affected if these plugins had a serious security vulnerability: has a nice “active installs” stat for plugins now. WordPress SEO and WooCommerce report 1+ million active installs, and Pods (being a somewhat niche plugin) reports 30,000+ active installs. That is a lot of sites, and this is only three plugins.

So we have a platform (WordPress) that by itself is regularly targeted by attackers. Every plugin you have installed can be a possible attack vector. Installed being the key word–a plugin, even if deactivated, can still be used to attack you.

Many plugins will write code in a way that it will not be run without WordPress being loaded first. If you tried to point your browser to a specific file within a plugin, you should get a blank screen or at least nothing should happen. When this practice is not done, an attacker could target a specific file within your site–even if the plugin is deactivated–and if that file has a security vulnerability then it might still be able to be used to attack your site. If you are not using a plugin on your site, be sure to delete it rather than simply deactivating it to avoid issues like this.



My goal here is to help you realize what things as simple as minor updates, backups, paying attention to what you are installing to your site are all small things that are extremely important to the health and well-being of your site. An update increasing the version number by 0.0.1 does not make the update unimportant, as small as it may seem. Dr. Seuss offers some valuable advice that may help you remember this if you apply it to plugins:

A person’s a person, no matter how small.
― Dr. Seuss, Horton Hears a Who!

Don’t freak out and run away!


I have given you the knowledge you need to defend yourself from most attacks, and how to fix things after it has happened. Keep updated, play it safe, and be prepared.

Read more articles in ,

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top