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.

54

54 responses to “WordPress 4.2.3 is a Critical Security Release, Fixes an XSS Vulnerability”

      • 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?

  1. 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.

  2. 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.

  3. 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.

  4. 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.

    • 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.

    • 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.

      • “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.

  5. 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.

  6. 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

  7. 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?

    • 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.

    • 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.

    • 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.

  8. 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…

    • 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.

  9. 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.

    • 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.

    • 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

    • “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.

  10. 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!

  11. 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.

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.

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