WordPress 4.8.2 is out, featuring nine security fixes website owners will want to apply, well, now.
All told, there have been six updates this year featuring security fixes, including January’s silent patch for a nasty zero day, this being the first since May’s v4.7.5.
The maintenance side of the update features six other software updates but focussing on the bit that bothers Naked Security readers most, security, we see five Cross-Site Scripting (XSS) flaws (a perennially popular attack vector that refuses to die), two path or directory traversal issues, and one covering an open redirect.
There’s also the precautionary hardening of the $wpdb->prepare() method.
The problem isn’t a vulnerability in the core WordPress software itself, but in what the core might allow code in the vast ecosystem of WordPress plugins and themes to do:
WordPress core is not directly vulnerable to this issue, but we’ve added hardening to prevent plugins and themes from accidentally causing a vulnerability.
WordPress has a pretty slick security operation but the army of 3rd party plugins and themes are both the software’s best feature and its soft underbelly.
Most recently the Display Widgets plugin used by a reported 200,000 websites was pulled after it and three subsequent updates were discovered to contain a spam-enabling backdoor.
The hardening of$wpdb->prepare() is important because the best defence against SQL injection attacks is to ensure that SQL queries are correctly escaped. Escaping characters in a SQL query stops the database engine from treating user-supplied data as code, which stops hackers from corrupting queries to their own ends.
The best way to do your escaping, says WordPress, is by using prepare:
All data in SQL queries must be SQL-escaped before the SQL query is executed to prevent against SQL injection attacks. The
preparemethod performs this functionality for WordPress
So, developers will be using prepare precisely because it’s supposed to protect against SQL injection. Although updated versions of WordPress should be safe from buggy third party code, old ones may not be. Plugin and theme authors should test their code against older versions of the core.
These security fixes affect all versions before and including v4.8.1.
At least this is a relatively low-key update in what has been an eventful period for WordPress patching. As ever, the larger issue is who patches and how quickly.
Earlier this year, researchers discovered a privilege escalation flaw in a REST-API, which was quietly patched, as noted above. However, attackers were still able to exploit the issue to deface large numbers of unpatched sites even though WordPress has had automatic security updates since October 2013.
WordPress warns (its emphasis) that:
The only current officially supported version is WordPress 4.8. Previous major releases from 3.7 onwards may or may not get security updates as serious exploits are discovered.
It appears that, in this case, WordPress has backported the security fixes to every version of WordPress from the 3.7.* branch onwards. The following versions are protected: 4.8.2, 4.7.6, 4.6.7, 4.5.10, 4.4.11, 4.3.12, 4.2.16, 4.1.19, 4.0.19, 3.9.20, 3.8.22 and 3.7.22.
WordPress stats tell us that only about 40% of sites are running the officially supported version. That isn’t a surprise, independent research from 2013 showed that 73% of WordPress sites were running old software with known vulnerabilities.
That matters because criminals are looking for ways to compromise the maximum number of websites for the minimum effort and the WordPress installed base is huge: WordPress runs on around 28% of all websites.
It’s why WordPress updates release notes start with this simple advice:
we strongly encourage you to update your sites immediately.
Go and do it now.