WordPress Version? Make Sure You're Running the Latest Supported
It all started with Miles Davis in 2004, when WordPress 1.0 was released that is. Since then, the popular open source content management system’s releases have been named after a prominent Jazz musician. Researching this topic from a security perspective makes it quite clear why Jazz musicians are apt denominators for releases, since securing WordPress and keeping it secure over time must indeed feel like a jamming session at your local Jazz club.
What does this mean in practice?
Quoting WordPress Codex:
The only current officially supported version is WordPress 6.1.1. Previous major releases before this may or may not get security updates as serious exploits are discovered.
Which means that if you’re a WordPress admin, you should bookmark the WordPress Codex supported versions page to check which actual release contains the latest and greatest fixes. This is important, as from the project’s standpoint only the latest named release and its subsequent minor releases are guaranteed to get the appropriate security fixes. In other words, if you’re still jamming with some earlier, already disowned Jazz player, you better get with the program and upgrade – before you get pwned.
- Below, is an abbreviated list of named WordPress releases. You can peruse the full historical list on the project’s history page.
| Artist | Release Date | WordPress Release |
|---|---|---|
| Arturo | 2022-05-24 | 6.0 |
| Joséphine | 2022-01-25 | 5.9 |
| Art Tatum | 2021-07-20 | 5.8 |
| Esperanza Spalding | 2021-03-09 | 5.7 |
| Nina Simone | 2020-12-08 | 5.6 |
| Billy Eckstine | 2020-08-11 | 5.5 |
| Nat Adderly | 2020-03-31 | 5.4 |
| Rahsaan Roland Kirk | 2019-11-12 | 5.3 |
| Jaco Pastorius | 2019-02-21 | 5.2 |
| Betty Carter | 2019-02-21 | 5.1 |
| … | … | |
| Count Basie | 2013-10-24 | 3.7 |
| … | … | … |
| Miles Davis | 2004-01-03 | 1.0 |
Release Cadence
If you look at the release timeline, you will realize there is a new version to upgrade to a couple of times a year. In the earlier years new releases were less frequent, but also there were bigger compatibility issues to work with as well. A good indicator of that has been the DB version they report a given version to contain, which is an incremental numeric string that either stays the same between versions or increases. If it stays the same between versions, the DB schema is not something you have to worry about while upgrading to a newer version that time.
Which version of WordPress should I use?
As stated above, running an unsupported version of WordPress will expose you to unnecessary risk of getting hacked and the most straightforward way to mitigate this risk is to follow the latest officially supported releases:
Latest WordPress (on wordpress.org)A History of WordPress Vulnerabilities
In practice, WordPress does backport some of the security fixes, but it doesn’t mean that sticking with an older Jazz player will not bite you in the ankle in the long run. Reading through the security release notes, I discovered that often the project had backported patches up until 3.7, a.k.a. Count Basie. This of course doesn’t hold true for 5.8.2. for example, which resulted in patches being backported down to 5.2. Did this expiring X.509 CA bundle issue affect earlier releases as well? That the release notes did not divulge.
The wordpress.org support policy states the following (sic):
WordPress will be backported security updates when possible, but there are no guarantee and no timeframe for older releases. There are no fixed period of support nor Long Term Support (LTS) version such as Ubuntu’s. None of these are safe to use, except the latest series, which is actively maintained.
WordPress Software Dependencies
Another factor that makes upgrading difficult is the fact that WordPress depends on a certain version of PHP and MySQL/MariaDB. Keeping all the dependencies in sync and migrating to new database schemas is not necessarily easy. That’s why it may be easier to run the software on a hosted platform, as long as you can make sure that the provider is on top of their game.
The bottom line is that running an obsolete version of WordPress is not the only way to get hacked, as many of the exploitable vulnerabilities lie in poorly implemented and/or obsolete WordPress plugins. You may also be running a version of PHP that exposes your deployment through a vulnerable PHP component or a vulnerability in either MySQL or MariaDB, which may be present in one or both versions of the databases.
Layered security, anyone?
If you are a security conscious WordPress admin, you will most likely benefit from running the platform behind a web application firewall, such as the one provided by CloudFlare. Even if it will take the edge of most exploits out there, you should only use it as an added layer of security. It is not, however, an excuse for not upgrading to the latest and greatest.
Q: Why do you claim that WordPress’s history with vulnerabilities is sad?
A: I let the CVE details speak for itself.
Show me TEH research
In an earlier post I looked at jQuery vulnerabilities from a software dependency perspective. I did touch upon EOL versions of the library, but this time around I decided to focus solely on the WordPress obsolescence.
Rather than researching and detailing each vulnerability separately, it was easier to take the stance the WordPress Codex has taken, namely renounce all other Jazz players except the latest.
As with jQuery, I used a representative sample of 100k hosts from the total population of 1.7 million with the help of the following Shodan CPE query: cpe:/a:wordpress:wordpress.
The details grouped by Jazz musicians and their groupies are the following:
The Good
The first observation based on the 100k sample is that 34.3% of all the Wordpress installations are running a supported version. 28.4% responded in a way, where it is not possible to discern the version with any certainty. If we err on the side of caution it means that the remaining 37.3% are in fact obsolete, as decreed by the WordPress project.
The Bad
If we look at the release time for the obsolete group and state that 5.x versions are relatively fresh. The 5.x make up the majority of the obsolete, namely 28.3%. These are the ones that are still within reasonable upgrade path towards an officially supported version.
The Ugly
The beyond hope group then ends being 9%, for which the oldest single instance was still hanging out with the charismatic Ella Fitzgerald (2.1) released in 2007-01-22. It is surprising how that host is still up and running. This group doesn’t have any reasonable upgrade path other than a complete reinstall on a newer platform, the operating system included.
Lessons Learned
In this post I’ve looked into WordPress lifecycle management from the support perspective. It is probably the most successful LAMP (Linux Apache MySQL PHP) application still out there. As a CMS, it is a very popular and feature rich application, since you can create compelling content with it quite easily.
From the attack surface perspective it is also a very fat, feature rich target, since you have:
- PHP, which as an interpreted language is rife with attack surface, especially the RCE kind.
- MySQL or MariaDB which call for SQL injection.
- A plethora of plugins, which are the attackers’ number one target.
Earlier I researched public exposure related to management interfaces. In a sense WordPress CMS functionality is a management interface, which in theory could be separated out from the published content. This kind of separation would make it possible to segregate the content producers (dynamic content) from the content consumers (static content).
Static Code Generators to the Rescue
At the same time, the world has moved on where static code generators such as Hugo make it possible for you to create compelling content with this separation in place. You write your content with the help of Markdown and templates on your own laptop, whereafter you publish the generated website content to the actual web server. The attack surface of this approach is much smaller and LAMP is so 2004 (sorry Miles Davis).
TOP 5 Observations on WordPress Security
If we look back to the research results above, it is safe to say that:
- LAMP brings complexity which is difficult to deal with from the updatability perspective.
- Dependency to PHP and MySQL/MariaDB complicate the ease of upgrades and add a significant attack surface to the picture.
- Self-hosted WordPress is a recipe for disaster, unless you’re a seasoned sysadmin.
- Strictly speaking, only 1/3 of all the WordPress sites are running an officially supported version.
- The WordPress plugin architecture makes it too easy to undermine everything else done correctly from the security perspective.
Recommended Approach
Be as it may, the intent of this post was not to demonize WordPress, rather than give you the lay of the land when it comes to WordPress security. For the beginner or even experienced user, a safer choice is to use a clueful hosting service, such as Bluehost, Dreamhost or SiteGround, which are recommended on wordpress.org. On the other hand, if you know what you’re doing and can put in the hours to keep your platform up-to-date, using a CDN such as Cloudflare and their WAF in front of your self-hosted CMS will take out a lot of the pain.
Credits
- Hero image courtesy of Florence Viadana on Unsplash.
Give Us Feedback or Subscribe to Our Newsletter
If this post pushed your buttons one way or another, then please give us some feedback below. The easiest way to make sure that you will not miss a post is to subscribe to our monthly newsletter. We will not spam you with frivolous marketing messages either, nor share your contact details with nefarious marketing people. 😉