Zero Day XSS Vulnerability in WordPress 4.2 Currently Being Patched

Klikki Oy is reporting a new comment XSS exploit vulnerability in WordPress 4.2, 4.1.2, 4.1.1, and 3.9.3, which allows an unauthenticated attacker to inject JavaScript into 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.

Alternatively the attacker could change the administrator’s password, create new administrator accounts, or do whatever else the currently logged-in administrator can do on the target system.

This particular vulnerability is similar to one reported by Cedric Van Bockhaven in 2014, which was patched in the most recent WordPress 4.1.2 security release. That particular vulnerability was related to four-byte characters being inserted into comments, causing premature truncation by MySQL.

In this instance, an attacker posts an excessively long comment in order to trigger the MySQL TEXT type size limit, which truncates the comment as it is inserted into the database.

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.

In these two cases, the injected JavaScript apparently can’t be triggered in the administrative Dashboard so these exploits seem to require getting around comment moderation e.g. by posting one harmless comment first.

A patch from the WordPress security team should be forthcoming. At this time the team could not provide an ETA, but in the meantime there are a few things users can do to mitigate the risk.

“Your best option is to install Akismet (which has already been configured to block this attack), or disable comments,” core contributor Gary Pendergast said in response to inquiries on the WordPress #core Slack channel. “JavaScript is blocked by wp_kses(). Akismet blocks this specific attack, which gets around wp_kses()’s protection.”

WordPress users can also temporarily disable comments in the meantime until the patch has been issued by the WordPress security team.


50 responses to “Zero Day XSS Vulnerability in WordPress 4.2 Currently Being Patched”

  1. Argh, just finished updating my 60 or so sites this morning to 4.2! … very unhappy :(

    Now I can do it again, for about half of them, which can’t be autoupdated … that’s four updates this week. Slowly but surely my job changes from being a web developer to full time WordPress maintainer.

        • I hear you. A single point of failure isn’t ideal, but manually managing the number of sites you have now and will have in a year from now it’s scalable. I was also leery of the free price initially, because I don’t want to see them neglect it or shut it down due to it not being profitable or sustainable. So far so good on that front, but I’d pay them something to use it for sure. I wouldn’t mind seeing a flat rate price/year for unlimited sites. There are alternatives like ManageWP who would gladly take your money for similar services.

          • Thanks, I’ll take a look. This is the sort of stuff computers were invented for, so I shouldn’t be doing things manually. Although I need and want to be there when things update, because problems can always happen, mostly compatibility issues between WP, themes and plugins.

        • Matt, I learned a long time ago not to rush to install new version of wordpress, especially not a .0 version. I always give it a couple of days because this sort of stuff often comes up. This is a very complex product, and the chance of a security issue on a significant update is reasonably high. It’s one of the many reasons I don’t allow automatic updates either.

      • Yes. Well if you know any better system please let me know. I haven’t found one so far. Even though updating WordPress does take some time (including backups, checking if everything works, etc), it’s still a lot easier and faster then for example Joomla. It’s mostly the amount of sites for me plus the hight frequency of updates. If there would be just one or two updates a year it’d already be much easier.

    • Yeah, I feel ya!

      I manage about 50 WordPress sites (for a total of 250 sites using WP/Joomla/Magento/etc. across 10 dedicated, self-managed servers). Keeping up with so many sites / servers (by myself) can be quite the task.

      For WordPress, I use the “Advanced Automatic Updates” plugin. This helps a lot, but software updates (in general) aren’t perfect. So I still check each website to make sure they are operating correctly after each update.

      And of course, automatic updates only go so far. There are plenty of commercial plugins and themes that require manual upgrades (i.e., Themeforest / CodeCanyon).

      My experience with MultiSite:
      A few of my clients (the ones that have a lot of domains) use Multisite. It works pretty well, but MultiSite installations themselves have their own set of issues. Generally speaking, I try to avoid having everything “under one roof”, unless the sites are 1.) for the same client, and 2.) very similar in functionality.

      I’m open to suggestions. :)

  2. Wondering if anyone has a clear method for securing sites from this. Aside form disable all comments via a plugin. Sites using Disqus should be safe correct? Though is there still access to post to the comments endpoint even if Disqus is enabled? Thanks in advance!

  3. Here’s the part that disturbs me…

    “WordPress has refused all communication attempts about security issues from us since November 2014. We have tried to reach them by email, via the national authority (CERT-FI), and via HackerOne. No answer of any kind has been received since November 20, 2014. As far as we know, they have also refused to answer the Finnish communications regulatory authority who has tried to coordinate resolving the issues we have reported, and HackerOne staff who have tried to clarify the status of them.”


  4. Why are we writting about this if it isn’t patched yet? It’s very irresponsible to publicly announce these things until there is a fix… Now sites are that much more vulnerable because all the details are published and everyone is subjected to it.

  5. It is fairly trivial to make a plugin to hook in to the comment system and slash out all extraneous code. I’m not sure what stops wp_kses work here, but if a more aggressive system were used which just stripped out all HTML in it’s entirety, then you could presumably protect against this quite easily (at the expense of blocking all HTML).

    I don’t have time to make such thing right now. Hopefully the core team will have a fix in place before something like that is necessary.

    • That was my understanding from reading this post.

      I just added this to all my sites as an mu-plugin instead:

      This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
      Learn more about bidirectional Unicode characters

      add_filter( 'preprocess_comment', 'nyt_preprocess_comment' );
      function nyt_preprocess_comment($comment) {
      if ( strlen( $comment['comment_content'] ) > 5000 ) {
      wp_die('Comment is too long.');
      return $comment;
      view raw


      hosted with ❤ by GitHub
    • The original report suggests that the injected JavaScript will not be triggered on the admin dashboard. If correct, you could continue to use your admin account so long as you don’t publish and view the malicious comment. I’ve personally not tested that theory however.

      • I only use the admin account if I need to do “admin stuff”, for day to day activities (posting entries, comment moderation) I use a contributor account. Assuming the payload isn’t triggered under a contributor account I believe I should be OK, but I will still be very careful.

  6. I was auto updated and now it’s asking me to update my database, when I update my data base I get the following error: Catchable fatal error: Object of class WP_Error could not be converted to string in /home/doctorof/public_html/wp-admin/includes/upgrade.php on line 1459

    Any thoughts on how to fix it? Tried the usual methods (turning off plugins, default theme etc).


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: