Why “off-the-shelf” WordPress Security is Never Enough
WordPress (WP) accounts for more than 43% of all websites on the internet. This totals to over 835 million different sites. The stats also show a steady increase in usage over time, and has no signs of slowing down. I use WordPress a lot, and as a programmer who frequently interacts with other WordPress sites for clients, I started thinking “how robust is my WordPress security?”
As a CMS (Content Management System), WP holds the largest share by a long way compared to other providers. As an open source platform it is highly customisable, which for many website owners is great. However, this and it’s popularity also make it a prime target for cyber attacks. From outdated plugins / themes and weak passwords, there are many routes an attacker can take to attempt unauthorised access to your website. In this article I will be disclosing how simple it can be for an attacker to create an attack surface and how these can be mitigated.
The state of current WordPress Security
The most popular security plugin for WP is Wordfence, which boasts 5 million+ active users. However this only accounts for roughly 0.59% of WP sites. Others include All-In-One Security, Jetpack project and many others, each with less than 1 million active users.
This leaves the vast majority of WP sites unprotected, using only off-the-shelf security practices. As WP is open source, any hacker looking to create an attack can read through the code and look for any possible entry points. This is how my journey began.
What is OSNIT?
OSINT (open source intelligence) is the term coined to describe the action of intelligence gathering using publicly available information. Imperva says “the goal is to discover publicly available information related to their organization that could be used by attackers”.
Using OSINT, a hacker can effectively start building an attack surface to begin working through potential methods of attack on the target.
Enough introduction, here is how my analysis of WordPress started.
Testing WordPress Security
Finding the targets WordPress version
My first step in building an attack surface for WP began by finding a way to check a website to see what version of WP they’re running. WP normally automatically updates unless switched off, so most sites should be on the latest version. Regardless this is a good place to start.
On my WP site, under updates it tells me my version is 6.6.2. I take this and navigate to my admin login page, view source and search for that version number. I am met with this:

Clearly WP uses the version number on the end of the JS files it uses on this page, I can automate a check using C# for this using this code:

In this snippet, I pass the domain name into the method as a parameter, then firstly check for wp-login.php, if this http request doesn’t return source code I then attempt wp-admin which routes the user to the login page if not already logged in. I then perform a Regex search on the source code to return any values of “ver=” (which we saw in the last snippet before the version number) up until the first double quote. This returns other version numbers as well so I add the numbers into a list, sort them for the most occurring (which is the WP version) and print that to the console window. I’ve also included some basic error handling.
Extracting usernames (and passwords?)
This is perhaps one of the more worrying parts of this investigation. WP has its own APIs. Most of which needs API keys to access, however some endpoints are still accessible without authentication. To find a list of users you can ping a simple GET request to one of the endpoints.
In this method the domain is passed as parameters and a json response is returned from the WP API. I use JsonConvert to parse this response into a List object of the class shown below:

The Json response includes more data but none that is relevant here.
How can we use this?
Now we have a list of users (although it isn’t exhaustive) we have a good base point for a dictionary attack. This type of attack uses massive lists of common passwords and tries them all to attempt to gain access. However there is another method that can be taken here.
Using the usernames listed from the request above, we can attempt to find a list of passwords previously leaked in data breaches. I perform a search to a database of compromised credentials to check for username matches.

I loop through the list of users, printing the info to the console, then if a password check is required, I pass the username variable into a “CheckPasswords” function which performs the search.
Running this code as a test returns this result:

Although the first login didn’t return any passwords, the second returned 5 previously leaked passwords for the username.
If you want to check if any of your credentials have been leaked, haveibeenpwned.com will show you any leaked info that has been found online relating to your email addresses or usernames. I recommend checking and discontinuing use of any passwords listed.
Most people reuse passwords, so obtaining a list like this would be an attackers first port of call to try and gain access to your site. Alternatively, an attacker could create a list of similar variations of these passwords and use a dictionary attack to test through them.
Checking for vulnerable plugins
According to wpmayor.com “plugins make up a whopping 92.81% (of hacks)”. Meaning the next step to check my sites security is to find the plugins installed. I have added three options to my tool to check this.
- check a list of most common plugins (50)
- a list of popular plugins (1300+)
- plugins with known vulnerabilities (8000+)
The first two options I obtained the lists from WordPress’ official site, scraping the plugin page and returning slugs for the listed plugins. As for the 3rd option, I went to Wordfence to scan through all pages of plugins with listed CVEs. Although these results will only return plugins that have either been patched, or are listed as “will-not-fix”, this is a good starting point for an attacker as a site with bad WordPress security may not be up to date with the latest plugin versions.
To do this I created a simple script using Selenium, a web automation library that uses a chrome browser to programmatically navigate the internet.
This script quickly scraped the whole 445 pages of results returning a list of all the plugins with one or more known vulnerabilities. An attacker can then enumerate these plugins using a simple script. For this example I will run the most common plugin 1300 search on my own website:

Any attacker with a simple script can enumerate an endless list of plugins against a WordPress domain to figure out what is running and plan potential entry points. Vulnerable plugins have been known to be exploited for many attacks including (but not limited to):
- SQL Injection
- Arbitrary File Upload
- Privilege Escalation
- Cross Site Scripting
Conclusion
This review highlights the importance of securing your WordPress website from potential threats. WordPress’s accessibility and flexibility have made it the perfect tool for millions of users. But the popularity of WordPress also makes it a target for attackers. From simple version checking to more complex OSINT techniques, there are many ways that attackers can map vulnerabilities without basic security measures. Off-the-shelf security and authentication practices are not enough.
Steps for better WordPress security
Mitigating these risks starts with proactive steps like:
- Updating WordPress, themes and plugins
- Using strong passwords / Checking for password breaches
- Restricting access to public APIs
- Integrating trusted security plugins like WordFence
These steps ensure a safer environment for site owners, and a better all round WordPress security. It is important to understand the potential weaknesses in your setup. With appropriate precautions, we can leverage WordPress’s strengths and keep attackers at bay.
If this article has raised any concerns regarding your site or your current setup, get in touch to discuss your options and how we can mitigate any threats before they arise.
Speak To UsWebsite and Software Developer @ ReformaConsultancy
ThomasProudfoot