WordPress update 5.2.3: the Breakdown

The latest WordPress update (5.2.3) fixes a trio of XSS vulnerabilities in comments and media uploads respectively. While the vulnerabilities aren’t major, we still recommend you update as soon as possible! Given the choice between three small vulnerabilities or no vulnerabilities at all, the choice is obvious. You have a responsibility to your users not to expose them to cross-site scripting. We’re going to talk in detail about the vulnerabilities but before you read further, I’d recommend you go and install the update.

Go on.

I ain’t going anywhere.

Updated? Great, let’s move on.

Stored XSS in Post Previews

Up until the update, there was a piece of legacy code meant to fix JS issues with various nonstandard alphabets. It did this by converting UTF-8 URL encoding into HTML entities, which let attackers store XSS payloads in posts that could be tripped by an admin (or any user with higher privileges) previewing them.

caption: a spam comment link preview, seen via the WordPress admin panel

Keep in mind this is in posts, not comments. For this attack to work, the attacker would first need sufficient privileges to make posts, then the administrator would need to trip over the preview when they saw the post in the stack waiting for signoff. This is only a major vulnerability IF:

• Other vulnerabilities had allowed some sort of permission escalation, letting the attacker gain post privileges
• The attackers did a significant amount of social engineering beforehand

I could see an ambitious attacker getting a guest post on TechCrunch or another high-traffic WordPress site and putting a booby-trapped link in it, but—unless you’re a major, high-traffic site that allows guests posts or has lax permission control—the effort/payoff here makes it fairly unlikely.

Stored XSS in Comments

This is a bit gnarlier. WordPress were intentionally pretty vague about what actually happened, but I did some digging and I think I have a handle on it. It looks like wp_rel_nofollow_callback runs shortcode to parse HTML attributes, and that shortcode allows for escape sequences.

Thanks to wp_kses, rel won’t run in the comments, but wp_rel_nofollow_callback automatically adds a rel=nofollow to the tag. So, if an administrator or moderator edited the comment without removing the dodgy elements then saved it again, it would decode the escape sequences, and suddenly you’ve got a malicious script running in your comments.

Sucuri did the hard yards and broke this down in more detail, so tip of the hat to them.

Again, because this requires the admin to do something pretty unusual (how often do you open a user-submitted comment in the editor, then save it without changing anything?) but it’s better to patch it and not worry that it will remain open as a vulnerability.

Reflected XSS in Uploaded Media

When a user attempts an upload but does not have correct upload permissions, they get a response from the system that contains both their upload’s file name and the HTML content type. This meant users could craft malicious file names and attempt to upload them, so the response would contain the XSS.

As of the patch, the response now uses text/plain instead of text/html, which should prevent this sort of attack in future.

With the aging infrastructure of WordPress and with attackers becoming more sophisticated, it’s more important than ever to take your website’s security seriously. Along the lines of security, you may also want to read up on the best WordPress plugins for spam protection.