Published on June 16th, 2013 | by Michelle Oznowicz0
WordPress Core is Secure – Stop Telling People Otherwise
WordPress expert Jason Cosper dispels the rumors—and clarifies the facts—surrounding the security of WordPress core.
By Jason Cosper | May 8, 2013
It’s time to clear up the WordPress security debate once and for all. Despite all the skepticism (and some haters), WordPress core is without a doubt one of the most secure platforms you can choose to put a site on. Period.
Since January 24th, 2013 no major vulnerabilities have been discovered inside of WordPress core. That means that across every (up-to-date) WordPress install on every hosting company across the internet, no vulnerabilities in WordPress core have been discovered. That’s unprecedented in open-source sofware.
If you’re skeptical, that’s reasonable. Sometimes it’s hard to ignore rumors. But I’m going to do my best to dig into this and (hopefully) change your mind. Not only am I the resident “WordPress expert” here at WP Engine—a company known for knowing WordPress—but I have also worked closely with the security team at DreamHost and spent a considerable portion of my youth running around in hacker circles in the greater Los Angeles area. I also like to spend my free time installing and running exploits and attacks against my own sites. Because if I don’t do it, someone will. And, honestly, I’d rather be the one that takes my own site down. It’s a dirty job, but somebody’s gotta do it…
Before I go into the backstory of the security debate, I want to address how important it is to remember that security is a shared responsibility between you, the user, and WordPress. WordPress will do its part, but you have to do yours too. There are three simple but necessary measures that site owners must adhere to in order to ensure optimum security: always have the latest version running, set strong passwords, and stay vigilant about security. As long as you have these three things down, you can rest assured that your WordPress site will be locked tight. Let’s break it down real quick…
1) Have the Latest Version Running
The first and most basic step you should take to secure your WordPress site is to always keep it updated to the latest release. The process of updating WordPress is simple and quick, and it’s necessary for helping patch security vulnerabilities. The details behind the latest security bug fix, and vulnerability, becomes public with the release of every new version of WordPress. When you update, your dashboard is upgraded automatically. Older versions of WordPress become obsolete because they do not have access to the most recent security patches.
Same is true for plugins; you should update your plugins every time a new version becomes available. And if you have plugins that you aren’t using, remove them from your dashboard.
2) Set Strong Passwords
One of the most common mistakes people make with WordPress regarding passwords is thinking that by using the WordPress admin password generated by WordPress during install time (which is in fact, strong) that their site is therefore protected from attacks. But just because this particular password is strong, i.e. consisting of lowercase and uppercase letters along with numbers and symbols, does not mean that your site is now completely protected.
To ensure password security, you must also make sure that your ftp/cPanel password for your domain is strong. The ftp/cPanel password for your domain is equally important to your admin password. If someone can access your cPanel then that person can delete your WordPress database from the cPanel >Databases >MySQL Databases. Not good. The bottom line is, use strong passwords for all entry points. It’s also recommended that your passwords be at least twelve characters, and that you change them occasionally.
3) Be Vigilant About Security
As far as being vigilant about security, there are a few things you can do. A great plugin for security is WP Updates Notifier. After it is installed and activated, WP Updates Notifier will detect any core, plugin or theme updates and notify the user via email. At this point the user can choose to upgrade their site, or its components, as they see fit. You can also check out Sucuri’s blog entries on WordPress to stay up to date on the best ways to keep vigilant. If you want to go even further, you can keep an eye on WPsecure to see if you favorite plugins crop up.
Recently, there was a large botnet that was trying to “brute force” its way into WordPress sites. But the botnet was unable to touch sites that limited the number of unsuccessful password attempts before locking IP addresses out of trying to login for periods of time. This functionality is something that WP Engine users already have. The Limit Login Attempts plugin is installed on all WP Engine sites.
WordPress Security Debate: How the Rumors Began
Several years ago, around the summer of 2009, WordPress took some knocks in the web publishing community for a series of security vectors that were exploited. Because the internet was beginning to realize WordPress had real potential to become huge, there was some well-intentioned criticism aimed at improving WordPress’s security. The criticism, in many ways, was the internet’s way of saying, “Hey there, WordPress, we know you are ambitious, and we love you for that, but we gotta know your security is bulletproof for your end-users before you get too popular.”
The WordPress Core developers responded to the criticism, and in the months that followed, added patches and tightened up security across the board. The result of that hard work is that today WordPress has more installations than any other type of website, over 64,000,000 at publication, and is one of the most secure CMSs you can choose for your website.
The Nitty Gritty
What specific security problems reared their ugly heads in the summer of 2009 and how exactly they were fixed?
There was a string of security patches that the WordPress core team began releasing in quick succession. The team was, in effect, rapidly going through and systematically closing off remaining security vectors on the project. By the end of the summer, the WordPress codebase had begun to look like Fort Knox.
The first problem was addressed with the release of WordPress 2.8.1 on July 9th, 2009. And it was kind of a doozy. Basically, a team of researchers at CoreLabs found an exploit that allowed unprivileged users to view files & modify some plugin options at their will. The next fix came just 11 days later when WordPress 2.8.2 was released. It addressed an issue with comment author URL sanitation. Basically, anyone who knew how to drop a specially formed link into the “Website” part of a site’s comment form could redirect admin users out of wp-admin to another site. Two weeks after that, the WordPress team released version 2.8.3. In it, members of the community had ferreted out a number of places where the privilege escalation issue—that was supposed to be addressed with the release of 2.8.1—hadn’t been fixed.
Fortunately, everything had been found by this point. But, as you know, software is only as secure as the latest version, and unfortunately a number of site admins still hadn’t even upgraded to 2.8.2. The sites running the older versions of WordPress were not safe from the old vulnerabilities.
And more updates were soon to follow. Version 2.8.4 of WordPress followed just 9 days later, adding one of the more important patches. Prior to 2.8.4, , any attacker (that used a specially crafted URL) could bypass built-in security checks and reset user passwords on any users that didn’t have a user_activation_key set in the database. This led to a rash of folks getting password reset emails when they hadn’t requested a reset. Which made a lot of folks assume their site had been hacked.
As summer gave way to autumn, the team worked through September and most of October before releasing WordPress 2.8.5. This was a hardening release that worked on tightening up security even more by bringing improvements from the actively developed (at the time) WordPress 2.9 back into the 2.8.x branch.
Compared to the reactive nature of summer’s releases, the patches in autumn were more of a preemptive strike. WordPress was learning how to stay vigilant and a step or two ahead of malicious code. Finally, a couple weeks before Thanksgiving 2009, WordPress 2.8.6 was released to address vulnerabilities that allowed logged in users (see: people with accounts on a site, but not necessarily admins) to modify files throughout the stack. The update made their user permissions ironclad.
The Fixes and Public Opinion
Let’s recap. In the span of just 34 days, four security updates were released for WordPress 2.8. That meant everyone running WordPress at the time had to update their site almost once a week to keep it from being hacked. And this was during a time before managed hosting or WordPress management tools made maintaining installs relatively easy. At the time, if you owned a site, you were having to test updates regularly.
Those updates resolved a number of security vulnerabilities, but there was still a number of WordPress users on 2.8.x who got hacked. I know because I was doing a lot of the cleanup work in 2009. This is one reason thought leaders in Information Security and web development harp on the importance of keeping your sites up to date, and why WP Engine and other managed hosts automatically update customer sites. The responsibility to keep the site updated falls squarely in the site owner’s lap. It doesn’t matter whether they self-update or rely on a managed host to take care of updates. It simply must be done.
After a couple months of relaxing silence, two more security updates dropped 23 days apart. And while these updates were more spaced out than their predecessors, there was a growing concern that the constant updates were just going to be “the way things were” moving forward.
If you were managing multiple sites in the 2.8 days, this whole run of updates was about as fun as standing in line at the DMV or having a root canal. Granted, WordPress’s built-in core updater had been added several months prior—and that all but killed having to deploy updates in a far more manual fashion—but being a WordPress Admin was still a massive time-suck.
Hacking is Newsworthy
It doesn’t matter whether the story is about a celebrity blunder or bored hackers trying to entertain themselves, the internet will sensationalize everything it can, and WordPress suddenly had a reputation, fair or not, for being a platform that always needed to be updated. In reality, by the end of 2009 WordPress had become secure enough for its end users, and the patches had laid the groundwork that made WordPress secure enough to be installed tens of millions of times on small individual blogs, to massive sites like The New York Times, and AllThingsD.
A lot has changed in the four years since WordPress 2.8. But some folks opinion of WordPress being insecure and problematic (see: almost any HackerNews thread about WordPress) hasn’t. And that’s a total shame, especially given how quickly technology changes. Anyone who makes their living in tech needs to spend the time necessary to stay up to date with major trends and developments. WordPress is the most popular software platform on the internet. Nothing else comes close to having as much adoption, and it always puzzles me when otherwise intelligent developers are completely unaware of how secure WordPress core has been for years.
That’s why we’re trying to help set the record straight.
The Bottom Line
While regular security updates still crop up in practically every major release of WordPress core (this is true of any piece of software: Ruby on Rails, Python, Drupal, Flash, etc.), things have managed to get much more sane on both the security & maintenance fronts. One of the biggest reasons behind this was the removal of a ton of legacy PHP4 and MySQL code in WordPress 3.2. And, it’s been a very long time since major security updates were called for. For proof, look at the list of WordPress versions in the Codex you should notice that the number of minor point releases (AKA, security & bug fix releases) has been reduced drastically since the release of version 3.2.
When a new version of WordPress is released, it’s been tested and retested. It’s ready for production deployment on each of the 64+ Million WordPress installations. Even minor bugs have been worried over and worked on to an almost obsessive level. At that scale, even the .1% security vectors should become downright common.
Still, WordPress users must be responsible for their own security, maintain strong Passwords, and keep plugins and themes up to date, as well as WordPress itself. The user’s responsibility will never go away. Many users who understand the value of extensive security host with WP Engine because we add additional security layers, like forcing strong passwords, and performing routine security scans. We also back up our security with a guarantee.
The lack of WordPress core exploits in recent history speaks volumes. It says that WordPress core is secure. So it’s time to put the debate to rest. Maintaining security is an on-going process, and constant vigilance is essential. But, the core team has done an amazing job to ensure the security of WordPress, and will continue to do so as the platform continues to grow.
We’ve reached a point in the history of the internet where WordPress has earned a reputation for its security. It’s time to act like it.