52 Comments

  1. Keith Davis

    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

    • Jeff Chandler

      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

    • Carl Hancock

      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

  2. Ryan Hellyer

    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

    • Jeff Chandler

      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

      • Ryan Hellyer

        I assumed it was left in intentionally.

        Report

        • Ted Clayton

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

          Report

        • Nick Halsey

          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. Chris McCoy

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

    Report

  4. Keith Davis

    Twenty Fifteen theme just updated to version 1.2

    Report

  5. Miroslav Glavić

    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

  6. Ajay

    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

  7. Amanda

    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

    • Ryan Hellyer

      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

  8. nvartolomei

    I will leave this here…

    https://hackerone.com/reports/14305

    Report

  9. Jason Kemp (@dialogCRM)

    Looks like WordPress version 4.2.2 released just now fixes the issue

    Report

  10. Jeff Chandler

    WordPress 4.2.2 has been released to address the Genericons issue and contains about 10 other bug fixes https://wordpress.org/news/2015/05/wordpress-4-2-2/

    Report

  11. Peter Cralen (@PeterCralen)

    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

  12. rahul286

    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

  13. alex

    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

  14. Pol Tajani

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

    Report

    • Ted Clayton

      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

  15. Jeffrey

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

    Report

    • Ryan Hellyer

      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

      • Jeffrey

        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

  16. alex

    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

    • Ajay

      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

    • Otto

      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

      • alex

        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

        • alex

          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

          • Samuel "Otto" Wood

            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

  17. Ted Clayton

    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

  18. Benjamin Intal

    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.

%d bloggers like this: