Cancel

Jeff Chandler

WordPress 4.2.4 Patches Six Security Vulnerabilities

WordPress 4.2.4 is available and patches six security vulnerabilities. The vulnerabilities were discovered by outside parties and members of the WordPress core security team. This release also fixes four bugs:

    • WPDB: When checking the encoding of strings against the database, make sure we’re only relying on the return value of strings that were sent to the database. #32279
    • Don’t blindly trust the output of glob() to be an array. #33093
    • Shortcodes: Handle do_shortcode('<[shortcode]') edge cases. #33116
    • Shortcodes: Protect newlines inside of CDATA. #33106

It’s been a busy year for the WordPress security team. Since the beginning of the year, there has been five security releases.

Users should check their sites to make sure they’re running 4.2.4. If your site hasn’t automatically updated yet, you should perform a full backup and manually update. Sites running WordPress RC 2 are safe since it fixes the same issues as 4.2.4.

Category:
Tags: ,
25

25 responses to “WordPress 4.2.4 Patches Six Security Vulnerabilities”

  1. You know, after all these years, this post was sort of late. I usually get my update notification from @WPTavern , I saw it from others earlier on the day.

    I am curious…WP is working on 4.3, they found issues and fixed it thus 4.2.4, I am going to assume that the 4.2.4 changes will be added to 4.3?

    Create forum topic from comment
    Reply

      • I am sorry but as long as WordPress allows any theme and any plugin to be activated, a WordPress site can NEVER EVER be secure, I don’t care who you are. The core should do a quick “security” check before activating a theme or a plugin – yes, it might take 5-10 seconds longer to activate them, but ensures that the entire site is safe, not just the core.

        As a perfect example, there is the “Dbox 3D Slider Lite” – the url is: wordpress.org/plugins/dbox-slider-lite – which contains the timthumb script in it’s includes folder… how is this plugin not compromising your site? WordPress should never allow this plugin to get activated – it’s that simple. And I am sure there are tons of other examples.

        So thanks for “keeping my sites secure”… but they really are not! The core is only one third of the security equation. How about the remaining two thirds – plugins and themes?

        Create forum topic from comment
        Reply

        • Thanks for pointing that plugin out, Nick! I’ve reported it to the Plugins team, they’ll work with the plugin author to get it fixed up. For future reference, you can report any plugins with security issues to plugins@wordpress.org.

          You’ll also be please to know that we’ve been experimenting with automated security scanning of themes and plugins, with some very promising results. It’s not quite ready for public release (it still needs further development work, and we’d also like to give theme and plugin authors a chance to fix any issues), but we’re at the stage where we’re looking at how to ramp it up to scan the entire repo – it should hopefully be giving us useful protection in the near future.

          Create forum topic from comment
          Reply

          • Gary, have you considered the idea of “common code” for plug ins and themes? That would mean taking these third party add ins and placing them into their own collection, to be reused by various themes and plugins?

            The concept is instead of having the same code replicated through different themes and plugins, that they could instead look for a common code base. It would shrink the code base and potentially limit problems when one of them turns up bad. Instead of having to patch an endless number of themes and such.

            Create forum topic from comment
            Reply

          • Gary, have you considered the idea of “common code” for plug ins and themes?

            I absolutely think that idea is worth exploring, it would probably be the most valuable use for the plugin dependencies ideas that get bounced around every now and then, and it’s a great place to start thinking about what plugin auto-updates would look like.

            There’s been some initial exploration into plugin dependencies – if this is relevant to your interests, and you have some time to spare, I imagine the team would appreciate your input. :-)

            Create forum topic from comment
            Reply

        • Code scans for any themes or plugins not coming directly from the repository (which should be scanned and held on upload) would be a fantastic feature. Great thinking Nick!

          I’d suggest making it impossible to activate a plugin which fails code scan (of course one could remove the security check module but that’s hard work). No exceptions for Automattic plugins either (I’m thinking of Jetpack specifically which gets a whole lot of free passes for its serviceware and promiscuous sharing of user data).

          Such a feature could finally bring the WordPress security wild fires under control.

          Create forum topic from comment
          Reply

      • Gary, thanks for sharing this information. Lack of long term security support has been one of my principal conflicts with Automattic/Wordpress.org. That WordPress.org is still supporting 3.7 is really good news. Keep up the good work.

        Long term stability and security are very important for publishers and businesses. The constant major update train is no way to run a non-technology related business.

        Create forum topic from comment
        Reply

        • I’ll just add a quick note that’s off topic.

          with Automattic/Wordpress.org.

          It’s just WordPress.org. ;) Automattic isn’t WordPress.ORG. It’s not word play; they do provide a great many resources and people but continuing to conflate them as the same thing just isn’t true.

          Long term stability and security are very important for publishers and businesses. The constant major update train is no way to run a non-technology related business.

          I’ve added emphasis to the quote. There is a business, but it’s not WordPress. If you are a paid WordPress developer or consultant and you are responsible for your customers sites and you feel that minor point revisions will negatively impact those sites then take disable auto updates. While I never recommend that, it’s an easy option to implement.

          If you do take that option then you’re also taking the responsibility if and when that customer site gets compromised due to an exploit in the wild. Also there’s the impact to the rest of the Internet. Auto updates were implemented because many users were not maintaining their vulnerable code. That was ruining the whole neighborhood and contributed to WordPress having an undeserved bad security reputation.

          WordPress updates are important and always get implemented in good faith to benefit the majority. Visit https://make.wordpress.org/core/ and read the #core Slack transcripts. There’s no draconian agenda here, just good people trying to make it all better.

          Yes, that sometimes causes problems for some, but what’s a good percentage for successful patching? Realistically, a 100% success rate without breaking anything anywhere won’t be achievable.

          Create forum topic from comment
          Reply

  3. Jeff, it should be pointed out that WP has been through three successive security updates in less than a month, all since the release of 4.2. It’s pretty disappointing to have to keep re-applying updates, I was in fact doing a 4.2.3 update when I noticed the 4.2.4 update notice.

    With hundreds of sites to patch, it’s almost a full time job to keep up with the security issues.

    Create forum topic from comment
    Reply

  4. Well, well, all I have to say is thanks to the WordPress team for all the hard work they put in.

    It is just funny how people complain about a free product and don’t make an effort to update the sites and only complain. BTW people some of you have their business build on a CMS like WordPress.

    When WordPress will have an 10 euros/dollars activation fee, I’ll join the complain wagon, till then enjoy the free product that enables your business to exist.

    Create forum topic from comment
    Reply

    • Time is not free Noni. Alex point is a good one: too many updates (many of which were breaking sites actively) is a high price to pay for free. I’d happily pay a $10 activation fee in exchange for security and no Automattic/Jetpack advertising on a level playing field.

      Create forum topic from comment
      Reply

    • Thank you for the kind words, Noni!

      We do appreciate that many folks have businesses to run based on WordPress, and that updates can take time (even with auto-updates enabled, you still want the peace of mind to check that everything is working correctly afterwards). Update fatigue is a real thing that can have an effect on your business, and your experience with WordPress.

      That said, the long term plan is more auto updates, rather than fewer. I’ll be happy when we get to a world where we push out a release every few days, consisting of just bug fixes, or a new feature when it’s ready to go. Part of that involves helping folks evolve their work processes to handle this frequency, and to trust that auto updates will just work.

      Create forum topic from comment
      Reply

  5. Alex, it should be pointed out that people who have hundreds of sites to patch and haven’t turned on auto-updates or aren’t allowed because of the network they’re on, like big gov’t networks, have to deal with that as a part of their job, just the same as the IT department has to stay on top of operating system and software updates. It’s no different.

    Otherwise, turn on auto-updates or migrate to a managed host that updates after performing checks, like WP Engine does. I had emails from all of my DigitalOcean droplets minutes after release and all 87 of my WPE sites were patched within 4 hours. That’s 100×4 security patches for 4.2 that I didn’t lift a finger to update.

    3 years I would have agreed with you before there were auto-updates and managed hosts were still kinda new. Now people have options, unless they don’t for protocol reasons, in which case, complaining is just complaining.

    Security updates are there for security, so I’d be careful complaining about updates that protect sites.

    Create forum topic from comment
    Reply

    • The point isn’t just safety, it’s also “what does this update break?”. Besides wordpress core updates, there are themes and plugins and they all can break too. Automatic updates allow any third party to submit something that just won’t work for your installation, and as long as that change passes the basic WP checks, you get an automatic update and as a result, an automatically broken website.

      This is VERY common when dealing with themes. Some designers have no problems completely changing the content of a theme and keeping the same name, which means if you updated, you get their new design, even if it’s entirely incompatible with your site. I have seen themes with broken headers, missing CSS code, and themes that were unable to render a single page after an “update”.

      I can’t take hundreds of chances for every update that comes up. The failure rate is just high enough to mean that almost every update will break something.

      Oh, and not to worry, I have decent scripts and methods to do server based automatic updates – when I am ready to do them.

      It points out perhaps another issue, the difference between core security updates, and “we added a flashy thingie sidebar widget” theme updates.

      Create forum topic from comment
      Reply

      • I can’t take hundreds of chances for every update that comes up. The failure rate is just high enough to mean that almost every update will break something.

        What do you think the failure rate is anyway? I’ve not seen official numbers but taking the temperature of IRC, *exchange and the support forums I don’t see anything that indicates an epidemic of problems.

        Yes, there are some that have problems with the auto updates. That’s usually due to someone using the API incorrectly and almost always by accident. That’s not assigning blame, that’s a fact and most do not have a problem with minor point releases.

        Oh, and not to worry, I have decent scripts and methods to do server based automatic updates – when I am ready to do them.

        Good. ;) If you’ve hundreds of sites that you’re mainlining for then sure, turn off auto updates and take responsibility for those sites as Jesse pointed out.

        It points out perhaps another issue, the difference between core security updates, and “we added a flashy thingie sidebar widget” theme updates.

        Minor point releases are always break fix and never add new functionality or “flashy thingies”. Major version numbers don’t auto update. That’s what this conversation is about right? Auto updates?

        Create forum topic from comment
        Reply

Leave a Reply

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.

You may also like

Newsletter

Subscribe Via Email

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

Discover more from WP Tavern

Subscribe now to keep reading and get access to the full archive.

Continue reading