XSS Vulnerability in Jetpack and the Twenty Fifteen Default Theme Affects Millions of WordPress Users

Jetpack and the Twenty Fifteen default theme have been updated after a DOM-based Cross-Site Scripting (XSS) vulnerability was discovered. According to Sucuri, any plugin or theme that uses Genericons is vulnerable due to an insecure file included within the package.

Genericons ships with a file called example.html which is vulnerable to attack from the Document Object Model level or DOM for short. The Open Web Application Security Project defines a DOM based attack as:

DOM Based XSS (or as it is called in some texts, ‘type-0 XSS’) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM ‘environment’ in the victim’s browser used by the original client side script, so that the client side code runs in an ‘unexpected’ manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

The payload for these types of attacks is executed directly in the browser. Even Sucuri’s website firewall is unable to block the attack since it never gets the chance to see it. The company however, has virtually patched the vulnerability.

Sucuri worked with a number of hosting providers to identify and remove the example.html file from their servers. If you use the following webhosts, you should already be patched as of a week ago.

  • GoDaddy
  • HostPapa
  • DreamHost
  • ClickHost
  • InMotion
  • WPEngine
  • Pagely
  • Pressable
  • Websynthesis
  • Site5
  • SiteGround

According to Sucuri, the example.html file was used for debugging and testing purposes but was mistakenly left inside the directory after the project was packaged for production environments. This simple oversight has placed millions of sites at risk as Twenty Fifteen is a default theme that ships with WordPress.

You should update the Twenty Fifteen theme and Jetpack regardless of which webhost you’re using. You should also remain vigilant and keep an eye out for additional plugin and theme updates. If possible, manually remove example.html from within the Genericons directory.

Update

WordPress 4.2.2 is available as a security update that addresses the Genericons issue and contains bug fixes.

52 Comments


  1. Where do you go to give up Jeff?

    If JetPack plugin and default WordPress theme aren’t safe… what is?

    I’ve just deleted Twenty Fifteen theme from all my sites – just in case.

    Report


    1. This is hard to convey, but the code inside Jetpack and Twenty Fifteen is secure, as far as we know. This time, they are guilty by association of using Genericons which has the bad example.html file.

      Report


    2. That’s the point. Nothing is safe. Which is why software updates and keeping a WordPress site up to date is such a critical piece of running a WordPress site.

      This applies to everything from WordPress itself, WordPress plugins, WordPress themes, the browser you are using, the operating system you are using on the device you are using. There is no such thing as bug free software and security vulnerabilities are a fact of life.

      But it shouldn’t scare anyone from not using software. Or WordPress. Or Jetpack. Or Twenty Fifteen. Just keep your software updated in a timely manner and you will likely never have a vulnerability exploited in between updates.

      Don’t keep things updated at all, or wait weeks to click update on plugins and themes… and all bets are off. It’s the big reason i’ve been a major proponent of expanding in some form the background automatic updates to plugins and themes and not just core as the suggested best practice.

      Report


      1. Completely agree with you. It’s important to monitor the updates on a daily basis ideally.

        Report


  2. Most of these security reports don’t surprise me. This one definitely did though. I’ve looked through that theme from top to bottom and would never have guessed there was a major XSS flaw in it.

    Report


    1. This is a vulnerability that to me, has come out of left field. Never would have thought such a small mishap like this could affect so many sites. I am very sympathetic to who ever it is that forgot to remove example.html from the Genericons directory before shipping it.

      Report


      1. Yes; “examples” sounds like a thoughtful usage-docs feature.

        Report


      2. Yes, the file was their intentionally, and its usage as such in core established doing so as a “best practice”.

        The entire genericons package has been included with all of the bundled themes since Twenty Thirteen, since WordPress 3.8. Specifically, this practice was introduced in this ticket: https://core.trac.wordpress.org/ticket/25085#comment:16. The goal was to make it easier to update the genericons package when updates were released, as well as to make its handling more consistent across the different themes. However, since the vulnerability was introduced in a newer version of genericons that is in Twenty Fifteen but hasn’t yet been bundled with Twenty Thirteen or Fourteen, the root cause of the example.html file’s presence was somewhat less clear.

        Bottom line, the issue was with Genericons itself, and everyone did a great job of addressing the issue in all of the widely distributed places that it’s bundled despite the timeline issues.

        Report


  3. just to be sure, you can run find -name ‘example.html’ -exec rm {} + in the dir of wp sites

    Report


    1. Right, and Jetpack is at 3.5.3, both had updates available before the news was published. Although themes don’t have change logs you can see, the most recent update is specific to this issue and removes example.html from the theme.

      Report


  4. Done updating MANUALLY.

    Thank you for whomever found the boo-boo and reporting it responsibly.

    Am I supposed to check EVERY folder of a folder for example.html ?

    Report


    1. you can run a find and rm through all genericon dirs like i did in one sweep

      Report


  5. Jeff, this is actually quite concerning. WP’s plugins and themes has always be plagued with security issues, both small and big, but I think something went wrong with the timeline on this one.

    Although many webhosts had this patched a week back, it clearly wasn’t the case with anyone not using them. I’m not sure what the right answer is when it comes to fixing security vulnerabilities, but I would think the updates should be out at least a day before this issue becomes public in cases where people knew about it.

    Looking at JetPack’s changelog, there were two updates yesterday without the fix and one today with the fix. If Sucuri knew about this a week ago, then am not sure why it wasn’t fixed in 3.5.1 or 3.5.2.

    Report


    1. Hmm, now that you bring it up, you’re right. Sucuri knew about the issue last week but the patches for Twenty Fifteen and Jetpack were released today. Something doesn’t add up.

      Report


      1. Exactly… Hopefully it doesn’t any sites badly. Especially those slow to update. This would actually have been the case when WP.org team should have pushed the plugin updates.

        The issue will always remain with themes because an auto-pushed update would never work since it might overwrite the customisation of many themes.

        Report


      2. Jetpack had been previously made aware of the issue, and was working with the Core Security Team toward a coordinated update and disclosure. Unfortunately, we weren’t given any advance notice of today’s disclosure, so the timing caught us before preparations were complete. Once the news was released — as the cat was then out of the bag — we pushed the update as quickly as we could, to secure as many users as possible.

        Report


      3. Thank you George for the explanation, appreciate it! Disappointing really as Sucuri is usually very good with these sorts of things. I hope we hear their side of the story soon.

        Report


  6. I’ve of course updated everything, including client sites, but what bothers me about this is (a) the fact that this wasn’t updated even though it was known about a week ago, and (b) all the tech sites wil of course flog the vuln, but no one will flog the fact that it has been patched. This isn’t technically a WordPress flaw, but a Genericons flaw, so strictly speaking anything using it should be either checking for the bad file in their packages or individually removing it on a case-by-case basis. Yet WordPress will once again take the hit.

    Report


    1. If you incorporate a faulty library, then I think it is reasonable to take the flack for it, particularly when that library is directly associated with your own project.

      Report


      1. From my recollection it was a distinct issue and addressed in the theme used on Genericons.com, as opposed to anything in the downloadable package — but I wasn’t the one who addressed it, so I can’t speak to the details.

        Report


    1. Thanks for leaving this. Definitely creates more questions than answers. If this was patched almost a year ago, then how did the faulty file get back in? Or was it never removed in the first place, until now that is?

      Report


      1. It looks like it was the same issue, but present on the main Genericons site. So they probably patched the site, but didn’t realise the same code was running in the example.html file.

        Report


  7. I am not sure if working with hosting companies is right and still don’t understand why these companies patched everything one week in advance compared to WP. It is WP issue, not hosting issue.

    Report


  8. If you are using EasyEngine, you can simply run `ee update` command and EasyEngine will block access to affected `example.html` file for all WordPress sites.

    Of course, upgrading WordPress is good but if you have hundreds of sites on a server, running `ee update` can come handy.

    Details: https://github.com/rtCamp/easyengine/releases/tag/v3.1.4

    Report


  9. Another day, another security problem with wordpress, and one that brings out a serious problem on the install and patch level:

    WORDPRESS DOESN”T DELETE OLD CODE, it just overwrites.

    What it means is that this “update” by itself doesn’t actually fix the problem unless you first delete the offending files. The example file occurs in a number of themes, and without manually removing the file, the security issue will not be easily fixed.

    My recommendation for wordpress is to stop working on 4.3, and start working on a version 5.0 – with the requirement of a full and complete deletion of code before the install. It’s time to clean up all of the old legacy code and stuff that ends up cluttering older installs.

    Oh, and getting to the third major update in a week is having a pretty serious impact on my productivity. The only part of wordpress scaling right now is workload to maintain the product.

    Report


      1. In this case, perhaps… generally it does not, and I can confirm that with old wordpress installs that have plenty of files left around that are no longer in use. It’s a full time job to manage core, plugins, and themes to make sure that security issues don’t exist, and to make sure you don’t have the NEXT security issue already loaded sitting unused in an old theme or plugin.

        Report


  10. All the recently discovered security issues, also confirm what I always said. Security plugins are totally useless…

    Report


    1. Security plugins are totally useless…

      Well, security plugins aren’t comic book super heroes. They aren’t warp drives, transporter or cloaking devices.

      They’re more comparable to safeties on firearms. Hard to say which would be more alarming, the guy who thinks a safety eliminates all the risk (and responsibility), or the guy who won’t use one because it doesn’t.

      Security plugins are extremely diverse tools, and most interesting to casually study & compare.

      My mother wouldn’t buy me a Superman cape when I was 4.

      Report


  11. I think QA team in WordPress should be responsible for this. How could this mistake pass the QA check before release?

    Report


    1. Because it wasn’t obvious. I don’t think I would have even noticed the problem had I been asked to audit that file.

      Report


      1. I agree. But if the QA team has a checklist when auditing files, it may help them catch these kind of mistakes. There should be a policy in place that requires QA team to ask developers to check off items from a list, such as debugging symbols, sample files, etc.

        Report


  12. I should also point out that any extra files or no longer in use files will not get deleted even by an update unless you first remove code. So as an example, Yoast recent “vendor” directory problem means I am having a fun time manually deleting his plug in from 200 sites and re-uploading it, because just uploading the new version would leave a bunch of files around. If any of them have any security issues (as examples seems to have from time to time) then there is potential that this is a problem down the road. How many other plug in and theme designers have removed unsecure or unwanted files from their updates without telling people they need to delete the unused files?

    I smell a ticking time bomb. Something old will come back to bite us all in the butt one of these days.

    Report


    1. Updating a plugin from the WordPress.org repository from within WP-Admin should delete the folder and then create a fresh folder with the updated version. I believe the same happens for themes as well.

      For manual updates, that is the same approach that needs to be taken. Delete the folder and upload a fresh copy of the updated file. Otherwise, as you say, something old will come back to bite us.

      Report


    2. This is false. Old files are indeed deleted by updates to both themes and plugins. For core, file deletions are rare, but they can and do happen.

      Report


      1. Otto, that is only true on automated updates. Manual updates (uploading files) does not such thing. The automated process does not apply to all installs – many are not automated because they don’t want their sites to get broken by unchecked updates.

        Report


      2. Let me add this: In this exceptional case code was added to the update process. Generally, this is not the case. Most theme updates are done without core updates, and theme updates generally don’t clean up.

        Report


      3. alex:

        First, if you follow the instructions for a manual update properly, as given here: https://codex.wordpress.org/Updating_WordPress#Manual_Update , then you might notice step 4 has the word “Delete” in it.

        Secondly, theme and plugin updates performed through the one-click process do indeed “clean up”, because they delete the entire theme or plugin directory during that process, and replace it.

        Simply overwriting files and leaving old ones around is not a proper way to do an upgrade, and it’s not the way done by WordPress itself or the way given in our instructions.

        Report


  13. No, Alex – this is too easy to test, scientifically.

    Just FTP a cruft-file up to a plugin or theme that is about to be updated. Follow through with the update. Observe the cruft-file vanish.

    Just now I had 2 plugins that were ready to update. (I get the notices, but I have a plugin that lets me do it with my own fingers.) I created a text file called “test.txt”, containing only the word “test”, and saved it on my desktop.

    In FileZilla, I navigated in my remote shared hosting environment (I also keep localhost environments) to the plugin that I am about to update, and uploaded “test.txt” into it. Then I hit Update in Admin. Then I hit Refresh in FileZilla. “test.txt” vanishes, right before my eyes, and all the file-dates change to today.

    Orphan files etc do not hang around in wp-content subdirectories, when a theme or plugin is updated. Those of us who tinker around with our own files in these content-subdirs, have known all along you have to have the mod-files somewhere else, when you click the update-button – or they’re gone.

    Maybe you’re thinking ‘Linux’, Alex. Ubuntu does quite a bit of ‘leaving’ of files for apps & packages, when they are updated or removed. We have a special app for hunting these down … and in an active environment we may have a series of the same file, with different dates or identifiers … and can revert or reset to a previous state, etc. Config files (of which Linux is fond) may also retain ‘dead’ values & settings.)

    Not in anything like a modern WordPress, though (and probably not in PaleoPress, either).

    Report


  14. For the past few weeks we’ve seen a ton of security updates and fixes. This should be seen as a good thing since this means security is an issue being taken seriously and addressed swiftly.

    The developer docs should get updated with notes regarding vulnerabilities and such if applicable (e.g. The recent XSS on some url functions)

    Report

Comments are closed.