Understanding WordPress Plugin Vulnerabilities

When WordPress vulnerabilities are disclosed in plugins, there are often many questions. Some are minor issues, some are more relevant, while others are what we’d categorize as noise. How are you supposed to make sense of all this?

To help provide clarity, are providing some insights into our assessment process. This post will help you understand the ones that matter and the ones that do not.

Scoring WordPress Vulnerabilities

We like to use the DREAD score when assessing vulnerabilities in WordPress plugins. A question we often get is, “Why didn’t you report on this recent release?” – or – “Why did you report on this release?”

DREAD allows us to take a more objective approach. It is a system developed by Microsoft many years ago (not widely used anymore). For us, it’s very useful for WordPress vulnerability disclosures.

DREAD breaks a vulnerability down into 5 categories:

Damage – How bad would an attack be?
Reproducibility – How easy is it to reproduce the attack?
Exploitability – How much work does it take to launch the attack?
Affected Users – How many people will be impacted?
Discoverability – How easy is it to discover the threat?

Each category gets a score from 0 to 10 and at the end, you sum them all and divide by 5 to get the final value.

DREAD Score Details

How we classify each category is what counts the most in the work we do:

1. Damage –
   • 0: Same as what the role has
   • 3: Information leaks
   • 5: XSS
   • 8: Authenticated RCE or SQL injections
   • 10: Unauthenticated remote command execution or SQL injections.
2. Reproducibility –
   • 0: Requires admin
   • 2: Requires editor
   • 3: Requires author
   • 6: Requires subscriber
   • 10: Unauthenticated
3. Exploitability –
   • 0: Fully manual and takes very long
   • 3: Hard to automate, requires author or higher
   • 5: Hard to automate, requires login
   • 8: Easy to automate, multiple steps
   • 10: One click in a browser
4. Affected users –
   • 0: Less than 1k installs
   • 5: 100k+ installs
   • 10: 1m+ installs
5. Discoverability –
   • 0: You have to attempt an exploit to see if it works or not
   • 3: You have to guess and it requires a log in
   • 6: You have to guess but can attack remotely
   • 10: Plugin announces that it is installed.

DREAD Scoring Examples

With these ranges in mind, let’s see how these recent vulnerabilities stack up. One thing you should notice is how we consider the role (or level of access) required to exploit the vulnerability as part of the overall score.

Gravity Forms: SQL Injection / Severity: Low

The gravity forms team fixed an SQL injection (SQLi) on the sort argument on their edit page. Only an authenticated admin or editor can actually reach that part of the code, and if an admin user is performing a SQLi attack, they are likely conducting a number of other attacks and SQLi is probably the least of your concerns. It can be used on targeted attacks (due to the lack of nonces) but we will not see any major issues coming out of it.

Looking at DREAD:

D: 8
R: 2
E: 3
A: 7 (paid plugin, so we don't know the number of installs)
D: 3

The final score is 4 (low)

Pods Plugin: SQL Injection / Severity: Low

The Pods vulnerability is actually very similar to the GravityForms and the WordPress SEO ones. Looking at the DREAD score:

D: 8
R: 2
E: 3
A: 2
D: 5

Final score is 3 (very low)

MainWP-Child: Password Bypass / Severity: High

The MainWP vulnerability was found by our team and we gave it a high severity. The reason we did so is that it was very easy to exploit (unauthenticated) and allows anyone to get admin access to the vulnerable site.

D: 10
R: 10
E: 9
A: 5
D: 6

Final score is: 8 (high)

WooCommerce: SQL Injection / Severity: Very Low

The WooCommerce vulnerability is interesting, but it requires an admin or shop manager in order to exploit it. We would not treat this as a vulnerability, but as a bug, since it does not allow more damage than what the admin role can cause.

D: 0 (same damage as the role itself can cause)
R: 0 (requires admin)
E: 1
A: 10 (1M+ installs)
D: 3

Final score is: 2 (very low)

WordPress SEO: SQL injection / Severity: Low

The WordPress SEO vulnerability got a lot of media coverage due to its popularity. Was it valid? Let’s look at the scores again.

D: 8
R: 3
E: 3
A: 10
D: 3

Final score is: 5 (low)

Judging WordPress Vulnerabilities

Judging vulnerabilities and their impacts is always difficult. A low severity score on DREAD doesn’t mean the vulnerability can’t be used on a targeted attack against your site. You should still update your site, even if the vulnerability score is low.

That’s why we always make sure our Website Firewall (WAF) is protecting against all vulnerabilities via our virtual patching technology. For every new vulnerability disclosed, our research team invests the time to test, verify and validate the impacts to ensure that our protection mechanisms are effectively protecting our users.

When looking at the internet as a whole, low severity vulnerabilities will have a small impact overall and require less marketing to get to the ear of the users. It’s also difficult to decipher the amount of noise being disclosed, we hope this helps provide some guidance into how to make sense of all the information you might be reading.

The Impact of Authentication

Contrary to popular belief, just because you hear the word “vulnerability” doesn’t mean someone can actually hack your site.

The real problems come with attacks that require no privileges at all – aka remote or unauthenticated attacks.

When an attack requires an authenticated user to be logged in, the severity drops. Keep in mind that it’s not that uncommon for sites to allow subscribers to register. So, if a vulnerability requires a subscriber user, these can lead to serious issues.

Once a vulnerability requires a higher role (like Author or Editor) then the severity drops quite a bit.

In security, this is why we place so much emphasis on concepts like The Principle of Least Privileged – the principle of giving someone the permission they require to do their job, no more, and no less. If they require higher permissions, then give them what they need, for as long as they need it, then reset the role to its original configuration.

If you are concerned that your site may be hacked, we offer a free guide to fixing a hacked WordPress site and are always here to assist you with securing your WordPress website.