A quick search through this website will find plenty of news alerts about security vulnerabilities in WordPress and its 40,000+ third-party plugins.
Don’t get me wrong – I love WordPress. It’s an extraordinarily good content management system for websites, and I use it myself for this site.
But I also understand that if you use WordPress, you really do have to take security seriously.
By the way, when I talk about WordPress security here, I’m referring to self-hosted installations of WordPress where you run the software yourself on a server.
I’m *not* referring to wordpress.com, where security is someone else’s concern (and they do a very good job of it), but which – in typical swings and roundabouts fashion – gives you a lot less opportunity to tinker with how your site works.
And if you find the difference between wordpress.org and wordpress.com confusing, you’re not the only one.
So, here’s the latest reason why you need to treat security as a priority if you run WordPress.
On Sunday, Finnish security researcher Jouko Pynnönen of Klikki Oy went public with details of a zero-day serious cross-site scripting (XSS) vulnerability in WordPress 4.2 and earlier.
A hacker could inject code into the comments form found on millions of blogs worldwide, which – when viewed by the site’s administrators – could allow them to change passwords, add new passwords or take other actions that would normally require website admin rights.
Here is a video (to rather more classy music than the typical zero-day exploit video receives) showing an attack in action:
Here is how Pynnönen described the flaw:
Current versions of WordPress are vulnerable to a stored XSS. An unauthenticated attacker can inject JavaScript in WordPress comments. The script is triggered when the comment is viewed.
If triggered by a logged-in administrator, under default settings the attacker can leverage the vulnerability to execute arbitrary code on the server via the plugin and theme editors.
Alternatively the attacker could change the administrator’s password, create new administrator accounts, or do whatever else the currently logged-in administrator can do on the target system.
If the comment text is long enough, it will be truncated when inserted in the database. The MySQL TEXT type size limit is 64 kilobytes, so the comment has to be quite long.
The truncation results in malformed HTML generated on the page. The attacker can supply any attributes in the allowed HTML tags, in the same way as with the two recently published stored XSS vulnerabilities affecting the WordPress core.
Fortunately, a few hours ago, WordPress has released a new security update which reportedly fixes the issue – version 4.2.1.
Some managed WordPress hosts, such as WPEngine and dxw did their customers proud by taking proactive steps to protect them before the official patch was released.
However, security researcher Jouko Pynnönen appears to remain frustrated at the tardiness of WordPress to respond to vulnerabilities he has uncovered:
“WordPress has refused all communication attempts about our ongoing security vulnerability cases since November 2014. We have tried to reach them by email, via the national authority (CERT-FI), and via HackerOne. No answer of any kind has been received since November 20, 2014. According to our knowledge, their security response team have also refused to respond to the Finnish communications regulatory authority who has tried to coordinate resolving the issues we have reported, and to staff of HackerOne, which has tried to clarify the status our open bug tickets.”
Quite why Pynnönen wasn’t getting a response from the developers responsible for securing the WordPress software is something of a mystery – and a concerning one at that.
With such a large part of the internet dependent on WordPress, it’s essential that vulnerabilities are found quickly and squashed promptly.
If you administer your own WordPress website, please be sure to ensure that you are running the latest version of the software and are keeping your plugins patched too.
As I described last week, take steps now to ensure that your WordPress site is hardened against potential attacks and your chances of compromise are minimised.
I've emailed the security team a number of times about security issues with both plugins and core and I've always found them extremely prompt in their reply (I'm talking about hours not days). Now it's been about a year since I reported anything so things may well have changed but I'm very surprised to hear this researcher hadn't revived a response for months.
I assume you've reached out to them, what was their reply?
I thought the classical music was a great touch to the video.
Part of the problem for non technical site administrators is the large number of version branches receiving updates coupled with unclear wording. The 3.7.* series is still receiving patches, yet in some site vulnerability checkers this will be shown as a red flag and an upgrade to 4.2 marked as "required" (the same is true for 4.1 sites on their latest release 4.1.4).
In the wordpress.org blog post 4.2.1 is announced as a security release for "for all previous versions" – well what does that mean in the above context?
The automatic update function makes the same mistake, stating a 4.1 site has been updated but that there is another upgrade "also now available". Where is the relevant information like the EOL date for the current branch?
No wonder, as you say, wp-engine and the like have become so popular! Security related announcements site owners are expected to cope with themselves need to be obvious, not obtuse
It's true, developers have this knack for not thinking of the user as much as they should, and they ignore that they are also users. I'm guilty as charged (although I do fix it when I realise it or it is pointed out to me). Anyway, to break this down for you a bit, software versions are (there's more than this too, but a common system is this, and it is what it seems to be wordpress uses) often thought of as trees with branches, such as:
major.minor.revision (simplified explanation, hopefully not too simplified)
… which is in this case, 4.2.1. And as for all previous versions in the context of 4.2.1. It is implied that 4.2.1 updates < 4.2.1 (so everything before it). Similarly, Windows 98 is more recent than Windows 95, and Windows 8 is more recent than Windows 7. Whether you call them updates or upgrades is probably mostly semantics (vendor specific or otherwise). So all versions that can be updated should be updated.
Why is there more than one major release (4.x.y, 3.x.y) ? Probably for those that still have older versions. I'll refrain from why those installations exist on the user side; I don't know why – wordpress isn't the only software that has this problem (it isn't always a problem, actually). One possibility – and I've not verified if 3.7 applies here – is that some older versions of wordpress used php < 5 and not all servers have it (this was some years ago, though, so many of those servers now have it).
As for its life cycle: good question; that they don't have that information readily available is a blunder on their part (not the only blunder though, is it?).
(And yes, there is something about programmers often – not always – being vague and outright cryptic with change logs. I'm a guru in this art although I've in more recent years been trying to stop this; thankfully most of what I work on doesn't need the raw changes made public; instead I describe any functionality change, feature addition, etc., and that is something I'm quite good at).
I do not have comments enabled but would this vulnerability exist for forms as well?
Whether it is vulnerable this time or not, I do not know. But it definitely could happen. But that's ignoring a more important point: you should make sure you have all security holes patched, regardless of whether you think it'll affect you (keep in mind, also, that one change in one module can break – or otherwise change – functionality in another). Although… I know wordpress has had a horrible fortnight or so. All the more reason to be sure you do have the most up to date version: there's been several security releases lately, and if nothing else does, that should wake you up a bit to the risks.
actually I'm all patched thx. Just trying to learn the full scope of the problem. I think if comments are susceptible forms may be as well.
Yes, very possible; they're similar in nature because after all, you fill out a form to post a comment. It is also user input which is a significant problem for all software: anything that can specified by the user (directly or indirectly) has to be sanitised and that is often not done at all (and other times not sufficiently). So yes, that is good reasoning on your part and that you're aware of this is crucial (as awareness is a very important thing).