WordPress 4.2 Stored XSS

Earlier this week WordPress 4.1.3. It fixed an XSS exploit discovered by a former student of mine. This week a new exploit – even in the new WordPress versions, including 4.2 – was uncovered.

Current versions of WordPress are vulnerable to a stored XSS. An unauthenticated attacker can inject JavaScript in WordPress comments.

If triggered by a logged-in administrator, under default settings the attacker can leverage the vulnerability to execute arbitrary code on the server via the plugin and theme editors.

Here’s how it works:

If the comment text is long enough, it will be truncated when inserted in the database. The MySQL TEXT type size limit is 64 kilobytes, so the comment has to be quite long.

The truncation results in malformed HTML generated on the page. The attacker can supply any attributes in the allowed HTML tags, in the same way as with the two recently published stored XSS vulnerabilities affecting the WordPress core.

Until a patched WordPress is available, it is wise to disable comments. I guess (read: think but haven’t tested it yet) that configuring your MySQL server with STRICT_ALL_TABLES would also work, as it should then trigger an error when too much data is attempted to being inserted.

UPDATE: Fixed in 4.1.4 and 4.2.1 (announcement). The rolled out fix checks the column length before actually tyring to perform the query. If the check fails, the query won’t be executed.

WordPress 4.2 Stored XSS →

Published by Bramus!

Bramus is a frontend web developer from Belgium, working as a Chrome Developer Relations Engineer at Google. From the moment he discovered view-source at the age of 14 (way back in 1997), he fell in love with the web and has been tinkering with it ever since (more …)

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.