Disclosure of Additional Security Fix in WordPress 4.7.2

WordPress 4.7.2 was released last Thursday, January 26th. If you have not already updated, please do so immediately.

In addition to the three security vulnerabilities mentioned in the original release post, WordPress 4.7 and 4.7.1 had one additional vulnerability for which disclosure was delayed. There was an Unauthenticated Privilege Escalation Vulnerability in a REST API Endpoint. Previous versions of WordPress, even with the REST API Plugin, were never vulnerable to this.

We believe transparency is in the public’s best interest. It is our stance that security issues should always be disclosed. In this case, we intentionally delayed disclosing this issue by one week to ensure the safety of millions of additional WordPress sites.

On January 20th, Sucuri alerted us to a vulnerability discovered by one of their security researchers, Marc-Alexandre Montpas. The security team began assessing the issue and working on solutions. While a first iteration of a fix was created early on, the team felt that more testing was needed.

Meanwhile, Sucuri added rules to their Web Application Firewall (WAF) to block exploit attempts against their clients. This issue was found internally and no outside attempts were discovered by Sucuri.

Over the weekend, we reached out to several other companies with WAFs including SiteLock, Cloudflare, and Incapsula and worked with them to create a set of rules that could protect more users. By Monday, they had put rules in place and were regularly checking for exploit attempts in the wild.

On Monday, while we continued to test and refine the fix, our focus shifted to WordPress hosts. We contacted them privately with information on the vulnerability and ways to protect users. Hosts worked closely with the security team to implement protections and regularly checked for exploit attempts against their users.

By Wednesday afternoon, most of the hosts we worked with had protections in place. Data from all four WAFs and WordPress hosts showed no indication that the vulnerability had been exploited in the wild. As a result, we made the decision to delay disclosure of this particular issue to give time for automatic updates to run and ensure as many users as possible were protected before the issue was made public.

On Thursday, January 26, we released WordPress 4.7.2 to the world. The release went out over our autoupdate system and, over a couple of hours, millions of WordPress 4.7.x users were protected without knowing about the issue or taking any action at all.

We’d like to thank Sucuri for their responsible disclosure, as well as working with us to delay disclosure until we were confident that as many WordPress sites were updated to 4.7.2 as possible. We’d also like to thank the WAFs and hosts who worked closely with us to add additional protections and monitored their systems for attempts to use this exploit in the wild. As of today, to our knowledge, there have been no attempts to exploit this vulnerability in the wild.

#4-7, #release, #security

WordPress 3.6: Menus

For menus we’re going to try to focus on some UI improvements. Menus work pretty well but users, especially the less-technical ones, are easily confused. We’ve seen them try to add menus without names because they see the “Create Menu” button before they see the menu name field, we’ve seen them add a bunch of menus instead of menu items because they’re unclear on the difference, etc, etc. The goal for the 3.6 cycle is to make menus a little more intuitive and user friendly.

@markjaquith and I are excited to have @lessbloat leading this. Take a look at all the user testing that has already been happening over at #23119 and make sure you comment here if you’re interested in helping out!

#3-6, #menus

WordPress 3.6: Revisions

Revisions are an extremely powerful tool for content tracking, but there are a few parts that need a little TLC. Ever since they were first introduced, there’s been a problem with proper author attribution on revisions (see #16215), and we’re going to take a crack at fixing that in 3.6. Additionally, while the current diffs are pretty cool, and make a lot of sense to those of us that look at diffs everyday, there’s a lot of room for improvement for your average user. We’d like to see some UI improvements around the diffs as well as information that makes more sense to an average content creator (words changed, a visual representation of what was added/removed, prettier output, etc).

@markjaquith and I chose @westi to lead this. I’m excited to see the improvements on this one! There’s a little of everything in this project, so please leave a comment if you’re interested in lending a hand.

#3-6, #revisions

WordPress 3.6: Editorial Flow

I’m really excited to see our editorial flow get some love in the 3.6 cycle! We always want to be as extensible as possible and post statuses are one of those places where we’re not near as good as we should be. The plan goes something like this:

  1. Fully support the existing register_post_status() API in core
    • Make sure things don’t break when you add your own custom statuses
    • Update the metabox UI to show any newly registered statuses in the drop down, etc.
    • Add a ‘moderation’ flag so that unpublished statuses can be explicitly identified
    • Support for non-standard public post statuses
  2. Enhance the existing API
    • Add support for registering post statuses to specific post types
    • Allow for caps checks on different post statuses
    • New remove_post_status() function for removing an already-registered post status
  3. Editing workflow for already published content

Additionally, we hope to address some issues around post meta for revisions, which is tightly related to the workflow for already published content.

@markjaquith and I have chosen Daniel Bachhuber to lead this. If you’re not sure why, just Google WordPress Edit Flow and it’ll all make sense. There’s a lot of heavy-duty under the hood work here, so please leave a comment if you’re interested in lending a hand.

#3-6, #editorial-flow

WordPress 3.6: the Post Formats UI feature

Post formats is going to be a major win for 3.6. It’s one of those features that has so much potential, but it really falls short in usability and honestly we haven’t really taken the time to truly show what it can do. We’re going to re-think the admin UI for post formats, similar to what Alex King did with his WordPress Post Formats Admin UI plugin. The goal is to make post formats much more user friendly and then show them off with the 2013 theme.

We’ve chosen @helen as lead for this project. Helen has done some amazing stuff customizing the post screen for various projects, and we’re glad to be able to leverage that for core.

Anyone interested in helping with this feature, please comment to let us know. The 3.6 schedule is considerably shorter than the 3.5 schedule was, so we really need to get moving on things as quickly as possible.

#3-6, #post-formats

Team Update: Headerators

We’ve pretty much wrapped up flexible headers (#17242) for both width and height. We’re currently reviewing a patch on #19840 and hope to have that finished this cycle. Our next project will be to work with Team Gandalf to help integrate flexible headers into their theme preview.

#3-4, #customize, #headerators, #team-update

Team Update – Headerators

We focused on flexible headers this cycle (#17242). We have a patch that we think is ready for commit, which adds flexible height and width. We had Nacin and Mark Jaquith look at the patch, they made some recommendations that we integrated, and it seems ready to go into core for some testing.

You can test with the latest version of the Essence Theme on Github or see comment 48 on the ticket for information on how to add support to your own theme.

#headerators, #team-update

I was considering adding another idea to…

I was considering adding another idea to the GSoC ideas wiki, but wanted to run it by the devs here first. Basically, making the login, registration, and lost password pages fully themeable. I know some work on this was started in #11172 with the creation of wp_login_form(), but we still seem to be pretty far from letting theme authors include login.php, register.php, and/or lost-password.php theme files.

If it’s something that everyone thinks is a valid idea and a project we would like to see, I’ll try to flesh it out and add it to the wiki.


Core Plugin Infrastructure Update

Just a quick update on where we stand with the infrastructure for core plugin development. The mailing lists are currently being used and it looks like they should be able to scale fine.

We still need a patch or plugin for Trac (https://core.trac.wordpress.org/ticket/11898) to help it handle the sheer number of plugins currently in the repository (not to mention the expected future growth). If anyone is able to help with that, please post on that ticket.

The next steps will be to rework the current layout of the plugin pages on wordpress.org. Currently there’s a link on the admin tab to that plugin’s Revision Log as well as the RSS feed for that log. That needs to be moved some place where regular users can see it. Additionally the plan is to add a way for plugin authors to request a mailing list for their plugin directly from the wordpress.org repository.

I’m excited to see all this fall into place so that we can turn the corner and see how core plugins will really shape up!


Core Plugin Infrastructure

As many of you know, last Thursday’s dev chat resulted in a core plugins research team team (for lack of a better term). Basically, our job is to try to come up with a list of tools that should be supplied for all core plugins, in order to allow teams of developers to be effective and efficient. It’s only been a few days so far, but we wanted to update everyone on our progress.

First, we started a new IRC channel on freenode to discuss core plugins. If you’re interested in offering suggestions or ideas, share them in #wordpress-core-plugins. The channel is logged at https://irclogs.wordpress.org/ as well, so feel free to put your ideas there even if no one is presently chatting. I’m sure a few of us will look at the logs (I know I do).

We also started discussing the infrastructure that is needed. It seems that plugins already have a good SVN system in place, which is great. Additionally we think core plugin teams need trac (which we already have, but it needs some work), and mailing lists. The way we see it, core plugins should have most of the tools available to WordPress core developers, since they’ll be doing the same basic thing on a smaller scale.

There’s still a lot to do, including coming up with suggestions on how core plugins should be developed, how developers will be added to or removed from a core plugin team, figuring out if any of the tools or processes would benefit all plugins (not just core plugins), etc. We’d love to get more input on these areas, either here or in #wordpress-core-plugins. Please remember though that we aren’t discussing what core plugins should be called, whether or not they’re a good idea, how plugins will become core plugins, or whether my mom’s a core plugin. We’re just trying to come up with a set of tools that would help the developers, and some basic best-practices for plugin development and team building.