Testing for XML-RPC multicall vulnerabilities in WordPress

In response to Sucuri’s disclosure last week regarding the possibility of brute force attacks via XML-RPC using the multicall method in XML-RPC.

Never heard of multicall?  You’re not alone.  Multicall allows you to send multiple XML-RPC requests in one POST, allowing, in theory, a bad guy to try hundreds of sets of credentials in a single request.  Due to the lack of documentation available online, it took me a while to get the syntax correctly, but I did get it sorted out, so, to save you some headache, here’s code that will try 39 incorrect sets of credentials, and then, if you change the details near the end (MYREALUSERNAME and MYREALPASSWORD), will try the correct credentials.  If you POST this to your site’s xmlrpc.php and get back a list of your users at the end of the response, that means you weren’t blocked out by any of your existing security tools and you are vulnerable.

The XML to POST is here:

In our testing, we confirmed that Jetpack Protect (and BruteProtect) DO block this attack vector.  If you’re running Jetpack with Protect enabled or you’re running BruteProtect, you don’t need to do anything to keep yourself safe from this, we’ve got your back!


Meta handling in WordPress 4.1

In light of 4.1’s status as a short cycle release, I would propose a handful of changes to be made around meta to better prepare us for a future that is less dependent on /wp-admin/ and more dependant on APIs. These changes will pave the road for future enhancements to the WordPress mobile app, as well as any non-wp-admin interfaces we may encounter in the future.

What I would propose is:

1) We build wrapper functions for register_meta

Those wrappers would be:
  1. register_post_meta
  2. register_user_meta
  3. register_term_meta
These three wrapper functions would accept the following arguments:
  1. meta_key (string)
  2. meta_format (string|array)
  3. post_type/term (string|array) (where appropriate)
  4. sanitize_callback (string)
  5. auth_callback (string)

The new item here would be meta_format, which would accept a number of options out of the box:
1. short_text (text that would be collected by )
2. long_text (text that would be collected by
3. date
4. datetime
5. color
6. image (this would be a field where an image is uploaded to the media library, and its ID stored in the meta_field)
7. number (possibly could be either a string: ‘number’ or an array: array( 'type' => 'number', 'decimal' => 2 ) )
8. select (would always be an array: array( 'type' => 'select', 'values' => array( 'English', 'French', 'Spanish', ... ) ) )

Additional Meta formats could be added programmatically via a filter.

In addition, we would determine default sanitizations for data UNLESS EXPLICITLY OVERRIDDEN. So, for example, short_text could be checked against wp_kses, color would get checked to only allow 3 or 6 hex characters, select would only allow strings defined in its declaration, dates would be re-formatted into YYYY-MM-DD, etc.

2) We announce that any interactions with undefined meta will be deprecated as of WordPress 4.5

Setting a fairly distant time horizon to allow developers plenty of time to update their themes and plugins.

3) Appropriate endpoints are added to the JSON REST API

Allowing application developers to obtain a list of meta definitions for every user/post/term, so that they can easily be modified through any future interface.

What do people think? I feel strongly that WordPress is in need of more powerful meta. We have the initial groundwork laid with register_meta, but it lacks the concept of meta formats, which would propel us forward into the API age.


Standardization of metadata in WordPress

Problem: Plugin and theme developers have no common naming scheme for post types and metadata, and they are not being properly registered.

Why it matters: If a common set of terms were used, it would allow users to easily migrate between multiple plugins of a given type (from one eCommerce plugin to another, for example), allow multiple plugins to work seamlessly with the same set of data.  In addition, by properly naming and registering metadata, it would allow for broader use of the API, as associated and related metadata would be easily accessed, understood and manipulated.

How to solve this: I would envision a solution which would involve the following:

  1. Consider requests to access/modify non-registered meta to be deprecated, and send up notices when WP_DEBUG is turned on
  2. When registering a new custom post type, allow a schema to be registered as well, for example:
    $args = array(
      'public' => true,
      'label'  => 'Event',
      'schema' => ''
    register_post_type( 'event', $args );
  3. Allow developers to identify schemas used in the readme.txt
  4. ???
  5. Profit!