WordPress is an Open Source CMS, meaning both: vulnerabilities AND their patches are all visible to the WordPress community. So how does this make WordPress secure?

If you studied in a more orthodox school, you might have dreaded tests, (at least I did.)

So when I first heard of the concept of Open Book tests, I thought it was a joke. I had a very similar reaction to what I learned about WordPress’ transparent security model, because I couldn’t even begin to understand how declaring weaknesses could be good for security.

But despite my opinions of what security should work like, WordPress is not only one of the most secure CMSes in the world, it’s also the most popular. How does the platform manage this feat?

Security through transparency

A concept that most Open Source CMSes use, security through transparency means that every vulnerability, (and its patch) is disclosed to the community using the CMS.

News about an attack not only alerts users of vulnerabilities, it also lets hackers know exactly what is vulnerable and how. The situation can be compared to a pharmacist seeing your prescription and having an idea of the illness you have.

This also means that those who maintain the vulnerable code (and the community) work to patch it as quickly as possible, and release it to all of their users.

This begs the next question:

What causes vulnerabilities in code?

There is no such thing as perfectly secure code. Nonetheless the possibility of vulnerabilities increases when:

• The code doesn’t follow the best security practices.
• The team working on the code isn’t experienced enough.
• The code doesn’t undergo multiple reviews.
• The team is ineffective or slow in acting on fixing known vulnerabilities.

How does security work on WordPress?

Well the answer lies in its community, and contributors.

WordPress consists of two main parts:

• WordPress core, which is basically the standard base and framework that any WordPress site is built on
• WordPress add-ons, which includes plugins, themes, and widgets.

Security for WordPress’ core

The core of WordPress is developed and maintained by a tight team with some of the best, most experienced security experts from around the world.

While it’s not possible to create perfectly secure code, these experienced security experts maintain the best WordPress security practices by ensuring that there are no obvious loopholes in functionality or in code that hackers could potentially exploit.

The code developed also undergoes multiple revisions for stability and security. This makes it more thorough.

But it doesn’t end there… if and when vulnerabilities are discovered, they are fixed as soon as possible, with the patch made available in the next release.

So while the are major releases  (such as WordPress 4.6) that deal with feature additions, special care is also made to make minor releases (like WordPress 4.6.1) that thoroughly deal with security issues.

As a result, there haven’t been any major exploits on WordPress’ core in a very long time.

Security for WordPress add-ons

Currently, there are close to 47,000 plugins and more than 4,100 themes listed on the WordPress.org repository.  There are also a very large number of plugins and themes hosted on third-party websites such as Themeforest, etc.

The WordPress community is very large, and the developers of these add-ons range from beginners to experts. Because of this, add-ons have many more vulnerabilities than can be seen with the WordPress core.

And even though these add-ons are open source, they have very few developers working on them. So with respect to security, not only do they not get the benefit of Open Source (which is that many people work on one project from many different perspectives), but they also suffer bad guys being able to exploit the additional visibility.

To add to this, we at BlogVault have seen a number of cases where sites have been hacked because the plugins or themes that they had installed didn’t follow the best security practices. This adds to their vulnerability.

Moreover, since a lot of the contributors are hobbyists, many of these projects get abandoned or do not get sufficient attention from the developers who made them time. This causes outdated plugins to have even disclosed vulnerabilities without a patch. The most recent case of this happening was that of W3 Total Cache plugin which was not updated for a considerable time even after a major disclosure.

Discovering vulnerabilities, declaring patches

In case of vulnerabilities, WordPress encourages the practice of “responsible disclosure”, which means reporting vulnerabilities directly to those who maintain the code they were found on. Whether this happens or not though, depends on who finds the vulnerabilities.

There are usually three kinds of people looking for vulnerabilities on WordPress:

• White-hat hackers, who are the good kind of hackers. They test systems and code for vulnerabilities. If they find any loopholes that can be exploited, they alert the developers in charge of the systems being tested.
• Hobbyists/users who either just stumble upon a vulnerability, or have the technical knowledge to recognize that the existing functionality/code could be exploited.
• Black-hat hackers. The bad guys who look for vulnerabilities to exploit.

This is why there’s always a race on. The first two groups (along with those who maintain the code), try to get a patch out as soon as possible, while the black-hat hackers try to exploit it faster.

Once a patch is worked on, it’s distributed via communication on the WordPress repository, WordPress news sites, tech blogs, etc.

The thing is, after a patch has been distributed, even a hacker oblivious to the vulnerability could easily reverse-engineer it to find out which part of the code was vulnerable, and how it could be exploited. Once they figure that out, it isn’t too hard to find out if sites have an outdated, exploitable version of WordPress, or a particular plugin/theme/widget.

So is a WordPress site secure?

It always looks like WordPress is under heavier attack because of the number of vulnerabilities which are disclosed.

This could be because WordPress is a popular CMS, and therefore a popular target for hackers… or because this is how security on WordPress works. Threats have to be disclosed so that users can prepare themselves. Patches have to be declared so that users are protected.

But to be honest, WordPress isn’t perfectly secure… because there is no such thing as a secure software.

Hackers are always trying to exploit sites for a number of reasons, so just as there are ways to patch vulnerabilities, there will always be ways to find ways around them, or pervert functionalities to create new ones. And just as hackers come from every corner of the community (and even from outside it), developers within the community rise to the occasion.
So while it might be impossible to make any WordPress site completely impervious to attacks, there are ways to harden websites, and recover quickly, such as implementing a reliable backup solution like BlogVault, and an intelligent malware cleaner, such as MalCare.