Securing WordPress Plugins from Attacker’s Perspective

Finding security vulnerabilities is an important part of securing our client’s sites. That is why WebARX is analyzing WordPress plugins for security issues and reporting them to competent developers or organizations. Using tools we developed at WebARX, this week we analyzed the source code of more than 20,000 plugins. Here is what we learned from the results.

Is your WordPress site secured? Take a look at how to secure your site here.

Feeling safe with sanitize_text_field()? Don’t!

We found a number of XSS vulnerabilities which developers are trying to prevent with sanitize_text_field function. In WordPress documentation we can see that this function does the following:

• Checks for invalid UTF-8,
• Converts single < characters to entities
• Strips all tags
• Removes line breaks, tabs, and extra whitespace
• Strips octets

Let’s take one plugin for an example. Probing input field with simple payload "><script>alert(1)</script>, the saved value was /"> which messed up the design a bit, but no JavaScript code executed. It seems to be very easy to trick yourself that nothing bad can happen.

Since we can escape from value attribute and set another, let’s craft a payload using “onfocus” attribute and see what happens. Entering abc" onfocus=confirm(1) autofocus="yes" which added “onfocus” attribute with javascript code as value combined with autofocus to execute payload without user interaction.

This particular plugin has over 20,000+ active installations and requires user type “Editor” to exploit the vulnerability.

LFI (Local File Inclusion) Mayhem

File inclusion vulnerabilities are mostly present in unpopular and old plugins, they don’t have many installs, but there is a lot of them. This issue is very critical and can be exploited in the wild. One of the plugins had an endpoint that was called from JavaScript on the main page. This particular issue didn’t require any sort of authorization.

In most cases, passing $_GET parameter to file_get_contents is critical, unless there is some sort of check before returning file content to the user. This type of vulnerabilities can lead to exposing various credentials.

SQL Injection is still out there

We found a couple of insecure and deprecated functions that can lead to SQL injection attack. Same goes with WordPress’s queries that are unprepared. Here is an example of a code that can lead to an SQL injection.

$query = "SELECT * FROM $wpdb->posts WHERE category=$category ORDER BY post_date";
$results = $wpdb->get_results($query);


Unfortunately, this usage is very common among new developers and older plugins. This can lead to a serious security vulnerability, but they are mostly exploitable to authenticated users only. WordPress has a great starting point for applying security best practice.

Securing your plugin

Finally, once you understand sensitive points in your application, you can secure it. Some programming frameworks are safe-by-design for some vulnerabilities. With Wordpress, it is very easy to get off the track with plugin security. The most important part is to ALWAYS filter and sanitize the user’s input and every time you deal with it – think about what the user may input.

Preventing input in some cases is not enough, to be sure that your site won’t render potentially malicious script you should secure output as well. WordPress has a list of helper functions that will do that.

WordPress has different user permission and sometimes they are not properly checked. Before you add functionality, think about which user type should have access to it.

Preventing CSRF attacks can be done with “nonces” in WordPress which is basically a token which validates that request came from a part of the WordPress and not some external, potentially malicious origin.