Stored XSS Patched in Wordpress 5.1.1

Security Risk: Dangerous

DREAD Score: 7.4

Vulnerability: XSS via CSRF

Patched Version: 5.1.1

WordPress recently released an update, 5.1.1, which patches a stored XSS vulnerability in the platform’s comment system. Even 10 days after the release of this security patch, around 60% of all WordPress sites scanned by our services didn’t have this fix applied.

We are not aware of any exploit attempts using the vulnerability currently.

Should I Panic?

This vulnerability requires some level of social engineering to be exploited, and as such it may seem like this attack would be very hard to perform. But history has shown us that bad actors are very effective at spamming WP blogs using similar techniques. All the traditional phishing techniques, some we even see in the wild, may be used as well.

With the market share WordPress has, thinking a certain number of site owners may fall to such techniques certainly isn’t a far fetched idea. You should update to the latest version as soon as possible.

How Does the Stored XSS Work in WordPress?

This bug can be exploited by chaining two attacks: a Cross-Site Request Forgery (CSRF) bug and a Cross Site Scripting (XSS) vulnerability. The reason for that, is the code vulnerable to XSS may only be executed when a user with at least Editor privileges is logged in.

In order for an attack to be successful, the attacker must then trick that user logged onto his site to click a malicious link. This may be more likely to happen if, for example, he posts a comment that contains the link on the targeted site.

Once he clicks on that link, a rogue script will perform a Cross-Site-Request-Forgery attack to make the administrator’s browser post a new comment, exploiting the XSS bug on his site.

The XSS vulnerable snippet, in the wp_rel_nofollow_callback function

As explained by the researchers who found the issue, the vulnerability can be seen in the above snippet. The wp_rel_nofollow_callback function is applied on hyperlinks in newly created comments and mistakenly assumed all of its attributes were using double quotes. This is an issue for two reasons:

Single quotes may be used too, making it possible to pass an attribute between single quotes that contained a double quote, thus breaking the generated hyperlink
This function is using shortcode_parse_atts, which as we’ve discovered in past vulnerability disclosures allows some unusual tricks to be performed, like decoding C escape sequences within the attribute’s content. This would basically make it possible to pass a double-quoted attribute containing another unsanitized double-quote, achieving the same result.

If the attack is successfully executed, a malicious JavaScript payload will, behind the scene, execute and use the administrator’s browser session to store a backdoor on the site.