Not long ago, Matt Mullenweg, the original developer of WordPress and CEO of Automattic, took to Quora to argue against those who were claiming that WordPress is not a secure content management system. A couple of days later, he must have been embarrassed to learn, a serious vulnerability was discovered in potentially dozens of plugins. And, to make matters worse, it was the fault of WordPress’ documentation.
Vulnerable plugins included such favorites as Jetpack, All In One SEO, Gravity Forms, and WPTouch.
In an impressive show of cooperation, Joost de Valk, who originally reported the vulnerability and who is the creator of the WordPress SEO plugin, which was vulnerable; the Sucuri WordPress security company; the WordPress security team; and numerous other plugin developers worked behind the scenes to implement fixes on as many plugins as possible.
In most cases, those fixes will be pushed automatically to WordPress users, but if you’ve got automatic updates turned off, you’ll need to do it manually. Some plugins, including WordPress SEO, opted out of the automatic update and will need to be updated manually, so be sure to check if any plugins on your WordPress site are asking for an update.
The vulnerability results from the misuse of a couple of very commonly used WordPress functions: add_query_arg and remove_query_arg, which are used to add and remove query strings to the end of URLs — the parts of the URL that follow a question mark and are usually used to pass information into WordPress and maintain state.
Ideally, any input that modifies URLs should be escaped and have any dangerous code rendered harmless. Otherwise, it can be used to inject malicious code into WordPress, which WordPress may execute. In the case of this pair of functions, developers assumed that the input was already being escaped by WordPress. They believed this because that’s what the documentation implied. In fact, no escaping was being done, which left users of plugins that included the affected functions vulnerable to Cross Site Scripting attacks.
Cross Site Scripting attacks depend on attackers being able to send code to the content management system and have it executed. Normally, that’s impossible because every potential opportunity to do so is escaped. A simple example of how an attacker might use this is as follows. The attacker embeds a link containing the code they want executed in an email or on an innocent website and then they influence someone with administrative privileges to click on that link. Because the site trusts the administrative user and she has admin privileges, the site will execute the code, potentially creating an admin user for the attacker, or some other behavior that benefits the attacker.
So, was Mullenweg wrong to defend WordPress? Can it still be considered secure? I think so. All software has vulnerabilities, and although this is an unfortunate incident, the WordPress development community could not have handled it better. Patches were available very quickly after the vulnerability became known, and most WordPress users were protected before they ever know there was a problem. This is how it’s supposed to work.