WordPress Files

How to Find WordPress Vulnerabilities Part 1

Blog WordPress Files How to Find WordPress Vulnerabilities Part 1

WordPress is the most popular CMS system used on the Internet with more than 26% of the market (august 2016).

The security in the Web and in WordPress is sometimes taken for granted. WordPress vulnerabilities could still be there, in its older versions, this is why your have to always update its core.

A thing we can do is to activate core autoupdates to be sure to get the latest update on DAY 1.

WordPress Vulnerable?

When a WordPress vulnerability is discovered, you can be sure at 99,99% that the patch is already there, included in a new minor version of your favorite CMS, WordPress.

So, basically, WordPress is secure, when you’re up to date, only when you are.

Now, remember that plugins and themes are the vector number one when we talk about hacking a WordPress Website.

Here comes some methods to find if your WordPress Website contains commons flaws, just by checking the front-end, not even at looking the code yet.

Test Login Page

Attackers will try to brute-force your password. First they have to find your login page. But on WordPress this page can easily be found. Just type http://example.com/admin and you’ll be redirected on the login page if you’re not logged in.

Then pirates will try some common usernames like admin, administrator or even your domain name, your own name etc, the goal is to get the WordPress error message indicating that only the password is bad, this means that the username has been found.

Now they will set up a brute-force script to guess your password, I hope you set a strong one or they will find it, for sure.

Here, the WordPress vulnerability lays in the fact that the login page is known from everyone, and also, your weak password (i hope it’s not!).

How to Prevent

  • You should move the login page, attackers, bots will be naturally blocked since they can’t even try to log in one time.
  • Then use strong passwords and force your users to use it for a best security.
  • Also, using a bad login attempts locker is a good idea,
  • Same for an auto-ban on non existing usernames.

Hit Hard on Home Page

Bots and attackers want to find sensitive contents on your website. It can be sensitive folders, files, access etc They are using softwares like the old DirBuster or the new Zed Attack Proxy from OWASP.

The software will hit your website, trying many many URLs trying to find one that return a positive status, indicating that, maybe something interesting has been found.

It’s common to use a test folder or an admin one, also a http://dev. domain, same for some files like config.old or backup.zip.

The WordPress vulnerability lays in the fact that many people are using temporary folders to keep sensitive data, and forget to delete it. Also the other flaw is to let bots search for these contents, you obviously should block that.

How to Prevent

  • You should use an anti brute-force on all your WordPress pages
  • You should block bad contents in the requests
  • You should block too long URLs

Use Another User-Agent

A User-Agent is a signature from your browser, each browser has its own, even crawling bots have their own. For example when Google will visit your website to be indexed, its known User-Agent is Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html.

Bad bots or Bots known as malicious also got their own User-Agents, they’re not welcomed on your website, you don’t need them, they’re just content stealers, email grabbers, stuff like that.

Also a User-Agent string can be spoofed and so can contains bad contents like <script> tags, if one of your plugins, themes or custom PHP script relays on this, you can be tricked, it’s not good at all.

How to Prevent

  • You should block bad bots
  • You should block bad User-Agents

Try Another Request Method

When you visit a website, you’re using the GET request method. When you send a form you’re using the POST method. You may already heard of this, but did you know that there is other requests methods?

HEAD, CONNECT, DELETE, PUT, PATCH, TRACE, TRACK, OPTIONS, or WHATEVER are other requests methods but your WordPress website doesn’t need all of that.

Attackers could use one of these methods to get into your website, get sensitive informations, you don’t want that, it could open some another WordPress vulnerabilities.

How to Prevent

  • You should just block non desired requests methods


Finding WordPress vulnerabilities is not just these four steps of course, and as I said, we don’t even talk about technical code here. Security is an everyday work and you should care about it.

SecuPress could help you to reduce your time spent on that.

Did you ever find vulnerabilities? Tell us how!