Unpacking The 7 Vulnerabilities Fixed in Today’s WordPress 5.4.1 Security Update
WordPress Core version 5.4.1 has just been released. Since this release is marked as a combined security and bug fix update, we recommend updating as soon as possible. With that said, most of the security fixes themselves are for vulnerabilities that appear to require specific circumstances to exploit.
All in all this release contains 7 security fixes, 5 of which are XSS (Cross-Site Scripting) vulnerabilities. Both the free and Premium versions of Wordence have robust built-in XSS protection which will protect against potential exploitation of these vulnerabilities.
A Breakdown of each security issue
Password reset tokens failed to be properly invalidated
If a password reset was requested for a user, but they then logged in and manually updated their password on the profile page, the emailed password reset link could still be used. Previously, the password reset link would only be invalidated if the user changed their email address. There’s not many circumstances in which this type of issue could be problematic unless an attacker already had access to a victim’s email account, which would effectively be a worst-case scenario. The code change (diff) in question is:
https://core.trac.wordpress.org/changeset/47634/
This vulnerability was independently discovered and reported by both Muaz Bin Abdus Sattar and Jannes.
Certain private posts can be viewed by unauthenticated users
This changeset had the following comment: “Query: Ensure that only a single post can be returned on date/time based queries.”
This indicates that it was possible for an attacker to view private posts by using date and time-based queries, though only for protected posts that were created or updated at the exact same time, down to the second, as an unprotected post. The diff in question is:
https://core.trac.wordpress.org/changeset/47635/
This was discovered by ka1n4t and appears to be similar to CVE-2019-17671, where multiple posts are returned from a query, and only the first post is checked to ensure that it should be publicly visible.
Two XSS Issues in the Customizer
These vulnerabilities appear to allow for corruption of post content by various users, and could allow for the addition of malicious javascript by an authenticated attacker with contributor capabilities. A user with the ability to write posts (such as a contributor or an author) without the unfiltered_html
capability and an administrator or editor could corrupt the data from each other’s drafts, potentially adding malicious JavaScript to a preview or final version of a post. The diff in question is:
https://core.trac.wordpress.org/changeset/47633/
These vulnerabilities were discovered and reported by Evan Ricafort and Weston Ruter.
An XSS issue in the Search Block
This actually appears to refer to two separate vulnerabilities with the same mechanism in both the RSS block and the Search block. An attacker with the ability to customize the class of either of these blocks (such as a contributor) could potentially set the block class in such a way that malicious JavaScript would be executed when viewing or previewing the post. The diff in question is:
https://core.trac.wordpress.org/changeset/47636/
This vulnerability was discovered and reported by Ben Bidner from the WordPress Security Team.
An XSS issue in wp-object-cache
The Object Cache is used to save trips to the database by caching content from the database and making the cache contents available by using a key, which is used to name, and later retrieve the cache contents.
In a few edge cases, an attacker with the ability to change object cache keys might be able to set one of these cache keys to malicious JavaScript. By default WordPress does not display these stats, nor does it allow users to directly manipulate cache keys.
It is possible that an improperly programmed plugin or combination of plugins could allow an attacker to manipulate a cache key and result in the unescaped value being displayed to an administrator viewing these stats via a plugin or custom code designed to display them. The diff in question is:
https://core.trac.wordpress.org/changeset/47637/
This vulnerability was discovered by Nick Daugherty from WordPress VIP / WordPress Security Team.
An XSS issue in file uploads
This particular vulnerability could allow a user with the ‘upload_files’ capability (Authors and above in a default installation) to upload a file with the filename set to malicious JavaScript, which might be executed when viewing the file in the media gallery. The diff in question is:
https://core.trac.wordpress.org/changeset/47638/
This vulnerability was independently discovered and reported by both Ronnie Goodrich (Kahoots) and Jason Medeiros.
An authenticated XSS issue in the block editor
This vulnerability existed in a few of the release candidates, and does not appear to have ever been present in an official release. It was discovered by Nguyen the Duc in WordPress 5.4 RC1 and RC2, and It was fixed in 5.4 RC5.
What should I do?
Although most of these vulnerabilities appear to be exploitable only under limited circumstances or by trusted users, the researchers who discovered these vulnerabilities may publish Proof of Concept code for them. Given more time, attackers may find that exploitation of these vulnerabilities is much easier than is readily apparent now. As always, we recommend updating as soon as possible.
This is a minor WordPress release, which means that most sites will automatically update. If your site sees a lot of traffic, you may wish to perform testing in a staging environment before updating the production version of your site.
Conclusion
We’d like to thank the WordPress core team and the researchers who discovered and reported these vulnerabilities for making WordPress safer for everyone.
You can find the official announcement of the WP 5.4.1 release on this page. If you have any questions or comments, please don’t hesitate to 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.
This article was written by Ramuel Gall, a former Wordfence Senior Security Researcher.
Comments