The WordPress 5.2.3 Security Release Unpacked
WordPress core version 5.2.3 has just been released. This is a security release which contains several fixes. I’m going to detail each of them below and unpack what each fix means and add any additional info that may be relevant.
Seven of the eight vulnerabilities fixed in this release are cross site scripting (XSS) vulnerabilities. Wordfence includes robust XSS protection in our free and Premium versions which will prevent exploitation of these vulnerabilities. The eighth is an open redirect vulnerability our team is monitoring to determine impact.
WordPress 5.2.3 Security Updates by the Numbers
This release contains eight security fixes which include seven XSS vulnerabilities and an open redirect. As a reminder, an XSS vulnerability is code that allows an attacker to send malicious output to a victim when they visit a website. This can happen because an attacker caused the site to store malicious data which is displayed later to a victim visitor (a stored XSS) or it can happen when an attacker crafts a link that displays malicious code when a victim visits that URL on a website (a reflected XSS).
If you’d like to go deep on cross site scripting (XSS), then visit our learning center article which explains exactly how cross site scripting vulnerabilities are created in PHP code.
This release arrived yesterday evening, so we are expecting full details of each of these vulnerabilities to be released by the researchers some time after the core release. This follows standard disclosure policy and gives WordPress users time to upgrade. In the meantime we will describe what we know about each vulnerability.
1. Cross Site Scripting in Post Previews by Contributors
This is a stored XSS. In examining a diff of the code changes, it appears that there was a stored XSS in the post-status field. That is, the field that stores the current status of a WordPress post. That field does not use a fixed list of possible values like a MySQL ‘enum’ data type, but rather reads the text value of the drop-down list and uses that.
This allows an attacker to create their own value for post-status and use that in a cross site scripting attack.
This is what the code diff looks like in post.js where the fix was implemented:
The attack vector in this case is that a contributor may be able to inject malicious code into post-status, which would then be viewed by a site admin with much higher privileges. That code would be executed by the admin with their privileges and the contributor, who is actually an attacker, would gain admin privileges by using the admin’s permissions to perform various actions.
Our team also speculates that this may be exploitable via malicious language packs, although we have not verified that attack vector.
This vulnerability was discovered by Simon Scannell of RIPS Tech.
2. Cross Site Scripting Vulnerability in Stored Comments
This appears to be a stored XSS and the announcement doesn’t provide any caveats with regards to user permissions. This is worrying because it suggests there is a stored XSS that affects the WordPress commenting system. This alone should strongly encourage users to upgrade ASAP.
The attack vector here would be an attacker posting a comment on a WordPress site and then someone with higher privileges like an admin viewing or moderating the comments and having code executed in their browser which could create a new admin user for the attacker.
This was also reported by Simon Scannell of RIPS.
3. Validation and Sanitization of a URL Leads to Open Redirect
An open redirect vulnerability is one that is often used in phishing campaigns. The vulnerability occurs when a website gives external users the ability to craft URLs that will redirect a visitor from the vulnerable website to any other URL.
In phishing attacks, an attacker will email a victim with the goal of getting them to click on a link. The link is to a trusted website which the victim recognizes. The attacker clicks on the link and one of several scenarios play out.
In a first scenario, the victim is taken directly to a malicious website where a vulnerability in their browser may be exploited.
In a second scenario, the victim may be asked to sign in to the legitimate website and is then directed to a malicious website where they may be asked to reenter their credentials. They may, for example, see a failed login screen and not realize they have been redirected. At this point their credentials are stolen.
In a third scenario, a victim may be redirected to a spam website after they clicked a link that was a URL to a trusted website with an open redirect.
There are many ways for attackers to exploit an open redirect and the severity of this vulnerability type should not be underestimated.
This vulnerability was disclosed by Tim Coen.
4. Reflected Cross Site Scripting During Media Uploads
This is another XSS which occurs during media uploads. In this case a user with lower privileges will upload media to the WordPress site which includes malicious code. This code would then be executed in the context of another user’s browser – and that user would have higher privileges.
In examining the code diff, it appears that until now, if you could jam an XSS payload into a media upload filename, this would result in an XSS. WordPress 5.2.3 no longer allows that attack vector.
This vulnerability was disclosed by Anshul Jain.
5. XSS in Shortcode Previews
Another XSS was fixed in the shortcode preview system. This vulnerability would allow a malicious user with lower privileges to inject code in a shortcode that, when previewed, would be executed in another user’s browser. If that user has higher privileges then the attacker may be able to perform actions as that user.
This vulnerability was discovered by Zhouyuan Yang.
6. XSS in the WordPress Dashboard
Ian Dunn from the WordPress Core security team discovered an XSS vulnerability in the WordPress dashboard. This vulnerability is a reflected XSS, which means that data is not stored, but rather is reflected back to a victim by an attacker. An example of this is if an attacker crafts a malicious link to the WordPress dashboard which causes their attack code to be executed in the browser context of the victim.
Full details of this vulnerability are not available yet, but what may be feasible here is for an attacker to provide a victim with a link to their own WordPress site dashboard. When the victim clicks the link, they visit their own site dashboard and actually execute malicious code, thereby granting the attacker access to their site. The malicious code may create an admin account, modify site content or perform other nefarious actions.
7. URL Sanitization XSS
Soroush Dalili from NCC Group disclosed an XSS vulnerability caused by URLs not being sanitized correctly.
8. jQuery Updated in Older WP Versions to Fix an XSS
jQuery is a javascript library used extensively by WordPress core and plugins and themes. A cross site scripting vulnerability was discovered in jQuery.extend and was fixed in jQuery 3.4.0.
WordPress uses it’s own WP specific version of jQuery. This fix in jQuery 3.4.0 which is detailed on the jQuery site in the changelog, was backported in to the WordPress version of jQuery. That version is listed as jQuery v1.12.4 in the source code comments. And they’ve updated the WordPress jQuery code without incrementing that version number.
Additional Notes
Change in edit-form-blocks.php
We also noticed a change in /wp-admin/edit-form-blocks.php which has switched from using file_exists() to is_file() in a conditional statement. Here is the diff:
When PHP is configured with “allow_url_fopen=On”, certain versions of PHP will allow the file_exists() function to fetch a URL. So this may also be part of a security fix or improvement.
Change in wp-sanitize.js
We noticed that this sanitization routine now includes recursion which will continue to sanitize text until the text no longer changes. It also uses textarea.textContent instead of textarea.innerHTML in the new version. Here is the diff:
What to do Next
At the risk of stating the obvious, update as soon as possible. This is a minor WordPress release, which means that most sites will automatically update.
If you’re running a high traffic production website with a dev/staging/production workflow involving a QA team, you probably need to run 5.2.3 on staging, let your QA team pound on it and then once they have worked through any issues, push to production. This takes time, but considering these vulnerabilities, I would recommend prioritizing this release over other projects.
The researchers who contributed these vulnerabilities to the core dev team will likely be releasing full details of each vulnerability fairly soon now that the core release is out. My guess is that the more professional researchers will release details in a week or two and others may release sooner. Once the details are out, these vulnerabilities are fully exploitable by anyone.
However, it’s worth noting that these vulnerabilities may become exploitable before details are released. The data released so far paints a bullseye on several areas of code in WordPress core, and by looking at a code diff, attackers can reverse engineer these vulnerabilities and develop exploit code themselves. For this reason, I strongly recommend that you update to 5.2.3 as soon as possible if you aren’t automatically updated.
In Closing
We’d like to congratulate the researchers who contributed fixes to WordPress core and express our appreciation to them for following responsible disclosure guidelines. Also thanks to the WP core team for implementing these fixes and helping keep the WordPress community safe.
You can find the official announcement of the WP 5.2.3 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.
Mark Maunder.
