Unpacking the WordPress 5.5.2/5.5.3 Security Release

On Thursday, October 29, the WordPress core team released WordPress version 5.5.2. This was a minor release containing bug fixes and security enhancements to the core WordPress content management system powering over one-third of the internet. There was a subsequent 5.5.3 release one day later; you can read about the emergency WP 5.5.3 release here.

As with every release, the Wordfence team analyzed this release to determine the severity of any vulnerabilities that may have been patched to ensure that Wordfence users are adequately protected by the Wordfence Threat Defense Feed.

In the WordPress 5.5.2 release, the core team patched 8 different vulnerabilities. We found that most of these vulnerabilities required some specific conditions which means that they would not easily be exploited en mass.

A Closer Look at the Changes

External Libraries: Disable deserialization in Requests_Utility_FilteredIterator
This was a fix to the Requests_Utility_FilteredIterator class.

Since this class implemented the Serializable interface but didn’t use a specific magic method for __unserialize, any PHP objects injected via a separate object injection vulnerability could use this as part of a POP chain to remotely execute code via the __construct method.

The fix involved adding an __unserialize magic method to handle objects injected via unserialization by doing nothing, rather than by using the __construct method that allowed code execution.

The good news is that a separate Object Injection vulnerability would need to be present in order for this to be exploited. Additionally, the proof of concept payload would fail the is_serialized check that WordPress uses to determine if data is in serialized format, so any plugins that used this check or the maybe_unserialize function would not be vulnerable to this payload.

See changes here.

Alex Concha of the WordPress Security Team contributed their work on this fix.

Embeds: Disable embeds on deactivated Multisite sites.
This fix appears to have been introduced to prevent content from being embedded in sites that were a part of a multisite installation that have been archived, deleted, or considered spam. This was a measure to help prevent spam creation using embed on multisite installations that have been deleted or archived. There is not much risk to site owners due to this vulnerability. If a site was compromised, this could possibly be used to further infect an archived or deleted site on a multisite installation.

See changes here.

Thanks to David Binovec for their work on this.

Coding standards: Modify escaping functions to avoid potential false positives.
This was a fix to escape the output of data that is echoed to certain areas in the WordPress admin dashboard. The core team added the function of esc_js to escape any JavaScript that could make its way into those fields. In this case, this was due to the fact that user input could be injected into the $pagenow global variable, so these changes prevent any injected JavaScript from being executed.

In addition, an additional function of absint was added to ensure that data fields that should only contain numerical data only have numerical data. This escaping would help to prevent any potential Cross-Site Scripting (XSS) that could be introduced into global variables as well as WordPress post slugs.

See changes here.

Props to Marc Montpas and Karim El Ouerghemmi for disclosing these XSS issues to the WordPress team.

Upgrade/install: Improve logic check when determining installation status.
This patch looks to fix a potential denial of service attack against the MySQL database. The WordPress installation page performs a number of checks to determine if WordPress has already been installed. These are done by querying the database and looking at the data stored there. It first checks to see if the siteurl option has been set by looking in the wp_options table. If it hasn’t, it goes down the list of WordPress tables to see if they exist in the database. If it is not able to find any, it determines that WordPress has not yet been installed.

In order for an attacker to exploit this, they would need to allow WordPress to connect to the database, but prevent the database from returning data from the checks performed above. There’s likely a timing element to this Denial of Service attack, as well as having a way to access the database. In many cases, MySQL databases are not publicly accessible. This does look to be exploitable by an unauthenticated user provided the other conditions are met.

See changes here.

Thanks to Omar Ganiev for discovering and reporting this vulnerability.

XML-RPC: Return error message if attachment ID is incorrect.
This is a correction implemented to verify that a media element retrieved using an XMLRPC request to wp.getMediaItem is actually an “attachment” by verifying that the post_type is that of an attachment.

This corrected a vulnerability that allowed users with the upload_files capability, like authors, to view posts that may have been hidden or in the draft stage. Essentially, an attacker could have read any posts regardless of the type contained in the wp_posts table due to the lack of check to verify that the attachment being retrieved by XMLRPC was actually a media attachment.

See changes here.

Thanks to Justin Tran for discovering and reporting this vulnerability.

XML-RPC: Improve error messages for unprivileged users.
This was a simple fix to change the capabilities required to comment on posts using XMLRPC. It appears that previous versions of WordPress did not do a check on the post to determine which state the post was in. This meant that it was possible for users to comment on private or hidden posts as well as drafts with limited privileges, using XMLRPC.

The good news is that, unless your site had anonymous XMLRPC comments enabled, then a user would need to be registered in order to comment using this method.

See changes here.

Props again to Justin Tran for discovering and reporting this vulnerability.

Meta: Sanitize meta key before checking protection status.
In this release, the WordPress Core team added sanitization to the meta_key value prior to checking its protection status in the is_protected_meta function. This fix was implemented to resolve a bypass in the function that would allow protected meta keys to be passed. This could have ultimately led to arbitrary file deletion.

The is_protected_meta function is used to determine if metadata is considered to be protected. In order to do so, the function checked for a simple `_` at the start of the meta_key to determine if it should be protected and not altered. This protection method could easily be bypassed by supplying a null byte in front of the `_` found at the start of the protected metadata key which would make it possible for “protected” metadata to be passed and used in other functions.

This vulnerability would require higher-level capabilities to exploit.

See changes here.

Props to Slavco for discovering and analyzing this and to Karim El Ouerghemmi for confirming.

Themes: Ensure that only privileged users can set a background image when a theme is using the deprecated custom background page.
This fix appears to resolve a Cross-Site Request Forgery vulnerability that could allow an attacker to change a theme’s background image in cases where a theme is using the deprecated custom background page.

The function used to change background images already had a capability check for edit_theme_options. This fix appears to add a nonce to that function to verify the integrity of the source of a request to update a background image.

Cross Site Request Forgery vulnerabilities require that a victim administrator be tricked into performing an action in order to exploit the vulnerability.

See changes here.

Props to Erwan LR for responsibly disclosing this vulnerability.

Protecting Wordfence Users

We’ve added protections in the Wordfence Threat Defense Feed to protect Wordfence Premium customers against exploitation of a number of these vulnerabilities. Sites still using the free version of Wordfence will receive these firewall rules on November 30, 2020.

Nevertheless, it is always prudent to ensure that your site has been updated to the latest version, now version 5.5.3, of WordPress to ensure that the core patches have been applied to your site.

What should I do?

Though most of these vulnerabilities do not appear to be easily exploitable, the researchers who reported these coding issues may publish Proof of Concept code that could lead to exploits against vulnerable sites. Attackers may find ways in the future to utilize unpatched code in ways that we might not find significant now. As always, we recommend updating as soon as possible.

This is a minor WordPress release, which means that most sites will automatically update. With the subsequent emergency release of WordPress 5.5.3, you should ensure that you have updated to the latest version. You may wish to perform testing in a staging environment before updating the production version of your site.

Conclusion

Thank you to the WordPress core team and the researchers who make WordPress safer for everyone.

You can find the official announcement of the WP 5.5.2 release here. If you have questions or comments, please post them below and we’ll do our best to answer them in a timely manner. If you are one of the researchers whose work is included above and would like to provide additional detail or corrections, we welcome your comments.

Special thanks to Matt Barry, Wordfence Lead Developer, Matt Rusnak, Wordfence QA Lead, and Ram Gall, QA Engineer and Threat Analyst for their analysis of this WordPress core release.