On January 6th, Automattic released an important security update for the WordPress core which addresses four separate vulnerabilities. WordPress website administrators are advised to update their websites immediately. All WordPress versions between 3.7 and 5.8 are affected by this, and the security issues include SQL injection, stored XSS and object injection, which we will review in this post.
Our firewall patches cross site scripting attempts as well as SQL injections by default so our clients should be protected from exploit attempts aimed at unpatched websites. If you are using our Sucuri Firewall make sure that you have bypass prevention rules enabled just in case!
Vulnerability Details
Fortunately, most of the vulnerabilities present in the WordPress core that were patched in this most recent update have prerequisites for them to be actively exploited. In most real-world situations they are unlikely to result in an actual website compromise, unless used in conjunction with other vulnerable software components. We’d like to take this opportunity to dispel some of the FUD surrounding the news of this most recent patch.
Interestingly, these security issues have been present in the WordPress core since at least 2013 when version 3.7 was released. One of the vulnerabilities patched only affects very old versions of WordPress dating back to 2009.
Stored XSS Through Post Slugs
One of the patches issued in this most recent update was to the following file:
./wp-includes/post.php
You’ll notice a very small but important change there which fixes a data sanitisation issue. Fortunately, the attackers would need at the very least an author level account to exploit this. The _truncate_post_slug function has been modified to encode characters such as:
< “ ‘
Post slugs are the content in the website URL address which comes after the domain in a web address. So if I were to write a post titled
Hello, world!
The post slug would be
hello-world
And accessed like so:
www[.]mywebsite[.]com/hello-world
Without proper data sanitisation, a malicious author or admin account present within the website could create a malicious post slug/title using those special characters to carry out an attack on the victim’s browser.
A compromised author or admin account on a website could carry out such an attack on an out of date WordPress installation, so this is a friendly reminder as to why it’s so important to lock down your wp-admin panel with two factor authentication or some other additional mechanism!
Object Injection in Multi-Site Installations
Fortunately this issue affects only multi-site installations of WordPress from quite a few years ago (version 2.8), so this would only affect a tiny subset of live WordPress websites and unlikely to cause any sort of real world compromise.
As you can see in the image, the subtle (but important) change is a modification to data serialisation that could result in an object injection during a core file update process from a (very) old version of WordPress <2.8 to a newer one:
$value = $row->option_value;
if ( ! @unserialize( $value ) ) {
$value = maybe_unserialize( $row->option_value );
if ( $value === $row->option_value ) {
The upgrade_280 function loads all wp_options values and unserialises them. Since this could potentially include user (ie: attacker) supplied data, it could result in a website compromise.
However, to reiterate, unless you are planning on updating a WordPress multi-site installation that hasn’t been touched since 2009, this is nothing that you would need to worry about.
Improved Sanitization Within WP_Tax_Query
Another vulnerability addressed in this most recent patch could result in an SQL injection.
So far the actual proof of concept details remain undisclosed, but it appears that the issue would only surface in plugins or themes that use this function in a certain way. This would indicate that certain prerequisites need to be met for it to be exploited in a real-world scenario, so the chances of it being used in a website compromise may be low.
SQL injection vulnerability in WP_Meta_Query
The fourth and final vulnerability addressed in the most recent WordPress patch is another improvement to data sanitisation.
The following files were patched:
./wp-includes/class-wp-meta-query.php ./wp-includes/class-wp-tax-query.php
To fix the $sibling[‘alias’] variable. This prevents attackers from injecting special characters such as
‘ “ ( ) and spaces
And instead replaces any non-word character (that is, not letters or numbers) with an underscore instead.
Again, it seems that multiple prerequisites would need to exist for a real-world attack to occur that would result in an SQL injection.
In Conclusion
Fortunately, all four vulnerabilities were found by security researchers before any attackers were able to exploit these in the wild (that we know of, at least). In all instances, responsible and private disclosure were practiced, allowing the good folks at Automattic to patch the issues and release a fix before any zero-day attacks occurred.
Versions 3.7 through 5.8 have been updated, so if you receive any “core files modified” warnings from any WordPress security plugin in use on your website you may want to double check if this was the cause before entering panic mode!
Big ups to the security researchers involved for making the web a safer place.
If you are stuck in an old version of WordPress due to custom code in your theme or plugins and cannot issue this patch please consider using our firewall to ensure that your website is not affected by these vulnerabilities!
