Mitigation? It doesn’t seem like you can guess anything about the content/structure of a JSON string without actually parsing it therefor it is probably a good idea to check that the length of the input “make sense” before processing it.

There is an exploit that can hit only those that know how to use linux to manage their site. Apparently linux editors store a backup copy of the file being edited in the same directory of the file. Therefor when a config file is being edited a copy of it is created, and since the names the editor gives to the backup files is predictable, and usually accessible as plain text from the web, all the data in the config is exposed at edit time. It is even worse if the editor failed to erase the backup after editing was finished.

Therefor you either should not edit config files locally, but transfer them over FTP, or put then in an inaccessible location (If wordpress is installed at the root directory you can put the config file at the usually inaccessible directory above it) or replace the config script with a script that read the config, or the secret parts of it from other location.

The news are that twitter got hacked and up to 250k user accounts where compromised. I’m not a real user of twitter although I have an account, so I might be wrong but in my opinion no one will feel extremely sad if some of his mental farts will be deleted or changed. Content on twitter, by the nature of the service that focuses on real time updates, is just not important enough in the long run.

But…. twitter is also a leading identity authentication provider on the web. If my twitter account was compromised it means that for a while the hacker had access to all the sites to which I have registered with my twitter account. It is hard to generalize how much cascading damage can follow from the hacker using my account, but it is not nice to even think about it. Twitter didn’t disclose the nature of the information to which the hacker got access, but I truly hope they don’t have a log of the sites to which I authenticate myself using my twitter account.

Yeh, the best that you can do is not to display them. All the site wide and per post options control whether the pingback/trackback will be stored in the DB, but the piece of code handling pingbacks from reception till checking if to put them in DB will always be executed.

This is probably not a big thing as I don’t remember exploits utilizing pingbacks, but it annoys me esthetically that an option described “Allow link notifications from other blogs (pingbacks and trackbacks.) ” doesn’t do what can be interpreted from the description (what it does is to set the default of the ping option on the post edit page).

xml-rpc protocol is basically used to expose a set of API implemented by a site/server which enables other software to interact with the site/server in a way which is easier to program then trying to mimic user interaction. WordPress currently (version 3.5) expose API for publishing pingbacks, and content. Software like windows live writer by Microsoft uses the content publishing API supplied by WordPress to create a non browser editing environment, but the main users of the protocol right now are smartphones because the small screen size makes the WordPress web interface almost unusable.

Upto WordPress version 3.4 the remote publishing by XML-RPC was disabled by default, and the text explaining the option in the admin was technical and said nothing about smartphones.

With the rise of smartphone use, and the number of smartphone apps that use XML-RPC to publish content to wordpress, it is only a logical move to enable XML-RPC by default, but the development moto of “decisions not options” was taken too far as in this case the option has enough importance to justify having it.

The reasons are mainly security related

It doesn’t matter how robust is WordPress code there is always a chance of a security bug that might relate only to the XML-RPC code

Plugin authors will probably start supporting XML-RPC opening more attack vectors, and user will not even know about it because it will not have any GUI indication, and you will not know that unless you read the plugins documentation.

There is no knowledge base on how to defend against brute force/dictionary attacks from XML-RPC. Current plugins might work,but will they give you a notice like “You failed to login 3 times, please wait 5 minutes till the next attempt” on the XML-RPC layer, and how the app will display that notice?

It might be that core developers are right and there is no risk added by having XML-RPC on all the time, but I think that a more conservative two step approach like

Make it default to on, leave the option in the admin

In two releases look at the experience of running WordPress that way and decided whether to eliminate the option as well

The reason it should work that way is that most user just leave the default setting on, so there will be a big enough user base to field test the feature even when the option to turn it off exist.