WordPress 4.2.3 is a Critical Security Release, Fixes an XSS Vulnerability

photo credit: Lock - (license)
photo credit: Lock(license)

WordPress users in the Americas woke this morning to find update notices in their inboxes due to a critical security vulnerability. WordPress 4.2.3 was released today and automatically pushed out to sites that have auto-updates enabled.

Because this is a security release for all previous versions of WordPress, those who do not have automatic update enabled will need to manually update their sites immediately. Core contributor Gary Pendergast explained the severity of the bug in the release post:

WordPress versions 4.2.2 and earlier are affected by a cross-site scripting vulnerability, which could allow users with the Contributor or Author role to compromise a site. This was reported by Jon Cave and fixed by Robert Chapin, both of the WordPress security team.

We also fixed an issue where it was possible for a user with Subscriber permissions to create a draft through Quick Draft.

Pendergast thanked all parties reporting vulnerabilities for responsibly disclosing them to the WordPress security team.

This release also contains fixes for 20 bugs from 4.2, including one that might require you to update your database before being allowed back into the admin.

wp-update-db

Not all WordPress users who are updating will be greeted with this message, but if you see it, don’t panic. It’s related to one of the bug fixes included in the release.

“It was a bug fix in 4.2.3, not backported – some versions of PHP didn’t run the utf8mb4 update correctly,” Pendergast said when asked about the required database update.

Unfortunately, in some instances, clicking the “Update WordPress Database” button may require multiple attempts. This is unusual but Pendergast said that improving database upgrades is high on the team’s list of priorities.

A list of all the files revised is available on the 4.2.3 release page.

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let's discuss your ideas.

54 Comments


  1. Isn’t it wonderful to wake up and get emails saying all of your WordPress sites have been automatically updated? And no managed WordPress hosting required.

    Report


    1. Yes, especially since I think this is already being exploited. I just got a comment moderation email for one of my sites, and I’m pretty sure it was an attempt to exploit this XSS vulnerability.

      Report


      1. I’ve just started getting comment moderation emails that used to go to the post author. This has only started since yesterdays update. The only place where my email address appears is in my user profile and I’m definitely not the author of the posts the comments are on so I’ve no idea how it’s picking up my email address! Unless, as you say, this is somehow an XSS issue?

        Any ideas?

        Report


      2. I don’t think that is related. What I was intending to say is that I am pretty sure that the content of the comment (which I did not approve, of course :-) was an attempt to exploit this vulnerability.

        Report


  2. Thanks Sarah
    Nearly all my sites have auto updated – just got one more to go.

    Report


  3. Thanks for the head’s up, Sarah! I have a client on managed WordPress hosting from GoDaddy. When these critical security updates for WordPress come out there is no way to manually update WP for my client’s site. It is simply awful! Sometimes it takes days for GoDaddy to push out the WP update. I contacted them about it and they said there team is aware of the issue but it does not speed things up.

    Report


  4. This update also causes a compatibility problem with a number of plugins and causes a problem to thousands of sites.

    Seems like shortcodes that have attributes with HTML content are broken. It’s reported in WP trac:
    https://core.trac.wordpress.org/ticket/15694#comment:24

    Bottom line is, now people need to choose between having their sites broken or running with a know security exploit. Not a very good set of options.

    Report


    1. This is a HUGE issue. Production sites are broken, and as you mention the only option is to revert to a version with a now highly public exploit.

      Report


    2. That’s why I don’t set all the sites I manage to “Auto Updates”. Need to expect this issues when they are new release.

      I’ll stick with working than broken websites. Daily backups will save me though!

      Report


  5. There is 3 “componets” of any WordPress website:

    1) Core
    2) Theme
    3) Plugins

    Anytime you update any of them, you risk your site being broken. remember the BACK UP BEFORE UPDATES warning?

    If you have an issue with a plugin having a conflict with the update, instead of complaining you can do the following:

    1) e-mail the author of the plugin with explanation of the issue.
    2) get a new plugin, for EVERY function you want, there are MANY options for plugins.

    Report


  6. The problem with all that, Miroslav, is that this is not coming from a plugin, but from a core update of WP that obviously wasn’t vetted or tested enough before 4.3.2 was released. Simply telling people to backup their databases and check their plugins are of no help when their production sites are broken.

    It does seem like WP is on the case and is developing a fix even as I type this.

    I have 2 networks using WP, and thus far my updates have been flawless, thankfully.

    Report


    1. I have a completely separate testing domain. has all the plugins my actual site has. I update there first.

      When betas come out, we get the “do not test on a live site” warning. Maybe we should all do that?

      99% of times it isn’t core itself but the theme/plugins that a site has that causes the issues. Specially sites that got their themes from “free WordPress themes” Google search.

      Report


    2. This release was tested for a duration of time orders higher than a standard full release would have been. There isn’t a fix coming, because there’s nothing to fix. The sites that are broken right now are from the couple of plugins that are doing really obscure things with shortcodes that would be impossible to whitelist. They need to update their code to follow the guidelines in the update Shortcodes API.

      Report


      1. “couple of plugins that are doing really obscure things with shortcodes”

        I will hond on what I think on this comment, but let’s call it just rude and really obscure. Simply stating that you can not whitelist something does not mean you can say that using shortcodes as HTML attributes is obscure, weird, rare or even not intended.

        Report


      2. This is not a helpful comments. There are reports of hundreds of websites no longer functional including two of my own. The WordPress folks need to get another update sorted today with this issued sorted!

        Report


    3. have the fixed this yet ? i have a new install with no plugins that will not send email.. and an old install that now will not send emails.. This is due to the Update!..

      Report


  7. We’re seeing some issues with various shortcode pluigins, including Toolset Views and Types. I hope there is a fix soon!

    Report


  8. We are also having major issues with Toolset Types and Views shortcodes breaking on this release of WordPress. We have around 100 sites running Types and Views, so this is a major problem for us.

    Report


  9. Also experiencing major, breaking issues on a number of sites, particularly those in which we’re using Types & Views. This update kind of makes me chuckles because Views, as a plugin, is pretty much based entirely on the functionality that this update just killed. Yay. Time to deal with the ensuing madness as all our clients email with brokenness.

    Report


  10. Stuck between a rock and a hard place here with multiple sites running Types and Views and 4.2.2. What gives? This’ll be a pretty major ordeal if we don’t get this functionality back…

    Report


    1. Roll back to 4.2.2 and turn off auto-updates for now to fix the issue on the short term. Then wait until the issue is fixed and update manually to 4.2.4 after which you can turn auto updates back on. Simple no?

      Report


      1. Note: Rollback is not possible with WP Engine hosting policy of automatic forced application of WP security updates. I had one website with them set not to update, was updated anyway.

        Report


  11. I appreciate that security issues need to be fixed as fast as humanly possible, but I’m now in a situation where I have sites that are broken because I use Toolset Types and Views. —Please insert the proper amount of polite outrage here—

    Report


    1. Have you informed the author of Toolset Types and Views of this issue so he/she/it can update Toolset Types and Views?

      Report


  12. A security fix should not have other updates rolled into it. It’s really bad form, and creates a horrible choice between “secure and broken” and “insecure and functional”.

    Report


    1. The only thing in the security release was security issues.

      Report


      1. Was it? I have Types and Views shotrcode rendering background image URL from post field broken after 4.2.3

        Report


      2. This is because the security vulnerability was found in the improper/lazy use of shortcodes. So the shortcodes had to be changed, thus breaking all the sites. That’s how I understand it anyway.

        Report


  13. here is an easy fix, this resolved WP 4.2.3 breaking some s2member shortcodes on one of my sites, should be similar for other plugin shortcodes that are enclosed in html etc

    use single quotes ‘ for html attributes surrounding the shortcode, and double quotes ” for the shortcode’s own attributes

    like this

    a href='[shortcode value=”foo”]’

    NOT like this

    a href=”[shortcode value=”foo”]”

    sam

    Report


  14. This is the second time a minor security release, an update that is supposed to be safe, has screwed over a significant portion of sites. Yes, I know the culprit are some plugins and themes that are using shortcodes in a non-standard way, but, after this, are we supposed to trust autoupdates blindly?

    Report


    1. While this hasn’t affected any sites I manage (touch wood) those sites do indeed, largely, include Toolset. So it *could have*.

      It concerns me that this mod was released with little fanfare. I’ve have no objection to tightening up “how things are done” – indeed on the contrary (for the obvious reasons.) But breaking sites, as has happened to some folks (again!), is counter productive.

      This is why average Joe’s and Jill’s don’t update their computers, phones, tablets. The knee jerk reaction to breaking changes, especially automatically induced ones, is to switch of those very changes. Ironically we (as technical users, developers etc) mock, laugh and ridicule them for, what is to them, a very human and obvious solution.

      It’s not like it’s a new phenomena. The road is well travelled, tons of use cases stretching back decades in different environments.

      Report


  15. Yesterday I woke up with many websites broken for this issue.
    Let us hope for a quick solution. So far I had to go back to the previous version on various websites.

    Report


  16. WooCommerce breaks as well, making it impossible for people to checkout. Even weirder, admins are able to checkout but not any other user roles. This needs to be resolved within hours.

    Report


    1. Have you found a solution Matthew? Right now people are able to check out on my site but they don’t get a confirmation page or email. Many people are hitting order twice now and I’m having to refund duplicate orders daily.

      Report


  17. I’ve personally never seen shortcodes used as attributes within html tags. Always glad I’ve got auto updates on, they’ve never messed up any of my websites or themes or plugins.

    Report


    1. Sometimes we need a dynamically generated ID or an extra class inserted in a list of posts. Toolset Views make this extremely easy to do. Nesting the quoted attributes with the new restrictions is an annoyance, but it sounds like it has to be done.

      Report


  18. Interesting that they’ve added “and later reported by Jouko Pynnönen” to the blog post now (you have the original snippet above without this). Jouko of course being the security analyst who previously released a 0 day vulnerability because the security team allegedly wouldn’t get back to him…

    Report


  19. We are experiencing problems with Google Analytics real time reports after the update!

    Report


  20. I would appreciate knowing how to get prior notification. How am I supposed to know ahead of time to clear my calendar to solve problems / check sites for a specific day? Thanks

    Report


    1. Unfortunately it isn’t possible to receive prior notification. When a security update like this is being crafted, it has to be done in utmost secrecy to avoid exposing the vulnerability. The security team doesn’t even expose the fact that they are working on an update as far as I know. But even if they did, it would be difficult for them to give an estimated release date. They want to get the update out as soon as possible, for obvious reasons; but they also don’t know how long it will take for them to fix it and test the fix.

      Report


  21. So the end result is tens of thousands of sites that went BACK to 4.2.2 or did a Google search to find that replacing the one file affected with the old version that still has the security problem are still vulnerable. Hundreds of thousands of sites got borked and it took WordPress 8 hours to finally make an official post about the problem and warn people (too late) not to revert or use the old file. Which, in turn, caused thousands more to decide WordPress can’t be trusted to auto-update their live sites (the livelyhood for many of them) and have disabled auto-updates for the future.

    If, as they claim, they couldn’t talk about it for fear of hackers finding out and exploiting it BEFORE the release, then there was certainly enough time to PROPERLY fix the issue that didn’t require breaking the internet. Or, once the security release was approved and released to the wild, they could have posted about the problem right then and there to prevent hundreds or thousands of people from wasting hours on research to figure out why their sites were no longer working.

    Overall, the WordPress folks have done a huge disservice to the community and their reputation by not handling this situation better. And I hope they’ve learned from it, but from everything I’ve read, they don’t appear to even grasp the gravity of what happened because they don’t live/work in the real world. It’s the same problem with how new versions are handled, they don’t understand how WordPress is used in the real world and they keep adding new features that make them happy, but not those of us who use it. The trust factor is diminishing and stupid stuff like this just make it worse.

    Report


    1. Dave, I can really understand your frustration. It’s really unfortunate when something like this happens and it makes people implement bad security practices. It would have been nice to see better coordination between the security team and the authors of the Toolset plugins and any other major plugins that were broken. However, I can understand why the security team may have decided not to do that. Also, sometimes it just isn’t possible to fix a security bug without breaking things permanently, so it might not have done a lot of good.

      I believe that the reason that there was not a post about the problem immediately after the fix was released is because the security team has a policy of not discussing vulnerabilities until all auto-updates have been rolled out. This seems like a good idea to me, but perhaps there are situations like this where it would have been better to make an exception. The problem is, that could put sites that haven’t had a chance to update yet at risk.

      Overall, I think this was a very tough situation, and I don’t think we will know for sure why things were done the way they were done for several days.

      Report


    2. Overall, the WordPress folks have done a huge disservice to the community and their reputation by not handling this situation better. And I hope they’ve learned from it, but from everything I’ve read, they don’t appear to even grasp the gravity of what happened because they don’t live/work in the real world. It’s the same problem with how new versions are handled, they don’t understand how WordPress is used in the real world and they keep adding new features that make them happy, but not those of us who use it.

      +1

      Report


    3. “they keep adding new features that make them happy, but not those of us who use it”

      WordPress wouldn’t be on the top 3 CMS list if people didn’t like it. Majority of users are happy with WordPress. Just because it upsets a few people, doesn’t mean they are doing things the wrong way.

      Report


  22. This is a big part of why I have a strong aversion to shortcodes. I hate the idea of crucial dynamic content being at the mercy of a parser – it just doesn’t feel very robust at all.

    They can certainly enable a lot of functionality for users without any development skill, but from my end of the court – making one-off client sites to spec – I’ve always greatly preferred baking the functionality directly into the template files and only exposing the necessary content bits to the editor. Decisions, not options!

    Report


    1. +1

      However, occasionally, ones left with no choice. Mostly due to the needs of clients.

      Report


  23. nope all of our WP sites will no longer send email after this update.. And one site is new with NO Plug ins running at all.. This is a huge issue!..

    Report


  24. My shortcode is working fine; however, the “Visual” portion of my posts are blank. The “Text” area is there. Unfortunately, deactivating my plugins did not help the matter. I have to be able to go into the Visual and copy and paste my recipes as I am working on cookbook deadline. The recipe plugin I use, the only way you can access the recipe content is via the Visual window.

    Any help would be appreciated.

    Report

Comments are closed.