PoC Report: CVE-2017-1001000 - REST API Content Injection

Executive SummaryLink to heading

• Objective: To test the ability to detect and prevent attacks that exploit the REST API to publish spam content (Spam/SEO Poisoning).
• Attack scenario: Simulate a hacker exploiting known CVEs to gain control and publish unauthorized content.

Vulnerability SummaryLink to heading

1. Identifier: CVE-2017-1001000
2. Vulnerability Type: Privilege Escalation, Authorization Bypass
3. Technical Description: The vulnerability exists in how WordPress processes POST requests sent to the endpoint /wp-json/wp/v2/posts/<id>. An attacker can submit an invalid ID (for example: 123abc), which can trick PHP’s integer filtering mechanism.
4. Exploitation Mechanism:

• • WordPress checks permissions based on the post ID. If the ID does not match any existing post (because it contains invalid characters), the system may skip the edit-permission verification step.
  • However, when performing the update, WordPress casts the ID back to a valid integer. As a result, malicious content can overwrite the target post without requiring an Admin account.

Target & ToolsLink to heading

• Tested Object (WAF): W7SFW
• Attack Target: WordPress (version 4.7.0 or 4.7.1)
• Attack Tools: Python Script, Postman, or WPScan

Execution Process (Attack Vectors & Steps)Link to heading

Phase 1: Reconnaissance & Code AnalysisLink to heading

Through analysis of the WordPress 4.7.0 source code in the file: wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php we can determine how the system defines routes for the REST API:

  register_rest_route( $this->namespace, '/' . $this->rest_base . '/(?P<id>[\\d]+)', array(
   array(
    'methods'             => WP_REST_Server::READABLE,
    'callback'            => array( $this, 'get_item' ),
    'permission_callback' => array( $this, 'get_item_permissions_check' ),
    'args'                => array(
     'context'  => $this->get_context_param( array( 'default' => 'view' ) ),
     'password' => array(
      'description' => __( 'The password for the post if it is password protected.' ),
      'type'        => 'string',
     ),
    ),
   ),
   array(
    'methods'             => WP_REST_Server::EDITABLE,
    'callback'            => array( $this, 'update_item' ),
    'permission_callback' => array( $this, 'update_item_permissions_check' ),
    'args'                => $this->get_endpoint_args_for_item_schema( WP_REST_Server::EDITABLE ),
   ),
   array(
    'methods'             => WP_REST_Server::DELETABLE,
    'callback'            => array( $this, 'delete_item' ),
    'permission_callback' => array( $this, 'delete_item_permissions_check' ),
    'args'                => array(
     'force' => array(
      'type'        => 'boolean',
      'default'     => false,
      'description' => __( 'Whether to bypass trash and force deletion.' ),
     ),
    ),
   ),
   'schema' => array( $this, 'get_public_item_schema' ),
  ) );

Logic Vulnerability Analysis:

1. Routing mechanism: The system uses the Regex (?P<id>[\\d]+) to validate that the id parameter contains only numeric characters. Up to this point, the implementation appears reasonable and secure.
2. Parameter Conflict: Due to the way WordPress REST API prioritizes parameter handling, when a request is sent in the form POST /wp-json/wp/v2/posts/123?id=456ABC, the id parameter in the Query String overrides the value that was previously validated by the Regex. As a result, the actual id value processed by the application becomes 456ABC.
3. Impact: An attacker can fully control the id variable through Query Parameters, effectively bypassing the initial Regex filtering layer.

Continuing the analysis at lines 93–98 (the post update functionality). The execution flow first calls update_item_permissions_check to verify permissions, and only then calls the update_item function to update the post.

Let’s take a deeper look at the update_item_permissions_check function:

 public function update_item_permissions_check( $request ) {

  $post = get_post( $request['id'] );
  $post_type = get_post_type_object( $this->post_type );

  if ( $post && ! $this->check_update_permission( $post ) ) {
   return new WP_Error( 'rest_cannot_edit', __( 'Sorry, you are not allowed to edit this post.' ), array( 'status' => rest_authorization_required_code() ) );
  }

  if ( ! empty( $request['author'] ) && get_current_user_id() !== $request['author'] && ! current_user_can( $post_type->cap->edit_others_posts ) ) {
   return new WP_Error( 'rest_cannot_edit_others', __( 'Sorry, you are not allowed to update posts as this user.' ), array( 'status' => rest_authorization_required_code() ) );
  }

  if ( ! empty( $request['sticky'] ) && ! current_user_can( $post_type->cap->edit_others_posts ) ) {
   return new WP_Error( 'rest_cannot_assign_sticky', __( 'Sorry, you are not allowed to make posts sticky.' ), array( 'status' => rest_authorization_required_code() ) );
  }

  if ( ! $this->check_assign_terms_permission( $request ) ) {
   return new WP_Error( 'rest_cannot_assign_term', __( 'Sorry, you are not allowed to assign the provided terms.' ), array( 'status' => rest_authorization_required_code() ) );
  }

  return true;
 }

Here, the id value that we control is passed into the get_post() function. Let’s trace into this function in the file wp-includes/post.php:

function get_post( $post = null, $output = OBJECT, $filter = 'raw' ) {
 if ( empty( $post ) && isset( $GLOBALS['post'] ) )
  $post = $GLOBALS['post'];

 if ( $post instanceof WP_Post ) {
  $_post = $post;
 } elseif ( is_object( $post ) ) {
  if ( empty( $post->filter ) ) {
   $_post = sanitize_post( $post, 'raw' );
   $_post = new WP_Post( $_post );
  } elseif ( 'raw' == $post->filter ) {
   $_post = new WP_Post( $post );
  } else {
   $_post = WP_Post::get_instance( $post->ID );
  }
 } else {
  $_post = WP_Post::get_instance( $post );
 }

 if ( ! $_post )
  return null;

 $_post = $_post->filter( $filter );

 if ( $output == ARRAY_A )
  return $_post->to_array();
 elseif ( $output == ARRAY_N )
  return array_values( $_post->to_array() );

 return $_post;
}

The get_post function then continues by calling the WP_Post::get_instance() function in the file wp-includes/class-wp-post.php:

public static function get_instance( $post_id ) {
  global $wpdb;

  if ( ! is_numeric( $post_id ) || $post_id != floor( $post_id ) || ! $post_id ) {
   return false;
  }

  $post_id = (int) $post_id;

  $_post = wp_cache_get( $post_id, 'posts' );

  if ( ! $_post ) {
   $_post = $wpdb->get_row( $wpdb->prepare( "SELECT * FROM $wpdb->posts WHERE ID = %d LIMIT 1", $post_id ) );

   if ( ! $_post )
    return false;

   $_post = sanitize_post( $_post, 'raw' );
   wp_cache_add( $_post->ID, $_post, 'posts' );
  } elseif ( empty( $_post->filter ) ) {
   $_post = sanitize_post( $_post, 'raw' );
  }

  return new WP_Post( $_post );
 }

The is_numeric() function checks whether post_id is a numeric value. If a value such as ?id=1abc is passed, the function will return false. As a result, the $post variable in the permission check function will hold the value false.

Consider the condition: if ( $post && ! $this->check_update_permission( $post ) ).

Since $post is already false, the entire conditional expression is bypassed. This allows an attacker to bypass the permission check and proceed to the update_item function.

 public function update_item_permissions_check( $request ) {

  $post = get_post( $request['id'] );
  $post_type = get_post_type_object( $this->post_type );

  if ( $post && ! $this->check_update_permission( $post ) ) {
   return new WP_Error( 'rest_cannot_edit', __( 'Sorry, you are not allowed to edit this post.' ), array( 'status' => rest_authorization_required_code() ) );
  }
  ...
}

In the update_item function:

public function update_item( $request ) {
  $id   = (int) $request['id'];
  $post = get_post( $id );

  if ( empty( $id ) || empty( $post->ID ) || $this->post_type !== $post->post_type ) {
   return new WP_Error( 'rest_post_invalid_id', __( 'Invalid post ID.' ), array( 'status' => 404 ) );
  }

  $post = $this->prepare_item_for_database( $request );

  if ( is_wp_error( $post ) ) {
   return $post;
  }
  ...
}

Here, the parameter $request['id'] is explicitly cast to the (int) data type. Due to the PHP Type Juggling behavior, a value such as 1abc will be converted to the integer 1. As a result, the system will proceed to update the content of the post whose ID is 1.

Phase 2: ExploitationLink to heading

To demonstrate the ability to overwrite parameters and gain unauthorized access to data, the following steps are performed:

Step 1: Request a valid post

Send a GET request to a post with a specific ID (for example, ID = 1) to verify that the API is functioning normally.

Step 2: Query a non-existent post

Test with a non-existent ID (e.g., ID = 2) to confirm the system’s default response (404 Not Found).

Step 3: Perform the Parameter Overriding technique

Use the endpoint of a non-existent post (ID = 2) while inserting an additional parameter id=1 in the query string. The result shows that the system returns the data of post ID 1, confirming that the ID control has been successfully bypassed.

Next, the vulnerability that allows a post to be updated without authentication is exploited.

By using the POST method together with the permission bypass technique analyzed in Phase 1, the parameter id=1a is submitted to bypass the authorization check. The system then implicitly casts the value 1a to 1, allowing the update command to be executed on the post with ID 1.

Result: Post ID 1 had its title and content successfully modified without requiring authentication.

After confirming that the vulnerability exists, we proceed to activate the W7SFW protection layer to evaluate the system’s defensive capability.

Once W7SFW is enabled, the attack payload is sent again using the POST method. This time, W7SFW blocks the request immediately.

ConclusionLink to heading

Through the process of analysis and the implementation of the proof of concept (PoC), several important conclusions can be drawn:

• Regarding the vulnerability: CVE-2017-1001000 is not merely a logic flaw related to parameter precedence (parameter conflict). It also stems from an inconsistency between the authorization check (which uses is_numeric) and the execution phase (which relies on integer type casting). This discrepancy in PHP type juggling creates an opportunity for attackers to completely bypass WordPress’s protection mechanism.
• Regarding the WAF: The deployment of W7SFW successfully prevented this attack.
• Mitigation: WordPress should be updated to the latest version as soon as possible in order to fully resolve the logic flaw in the REST API.