Exploit Research Plan - CVE-2026-39474

1. Vulnerability Summary

The Post Duplicator plugin (<= 3.0.10) for WordPress is vulnerable to PHP Object Injection due to the unsafe use of maybe_unserialize() on post metadata within its REST API endpoints.

The vulnerability exists in includes/api.php within the get_post_data() function. This function iterates through all custom fields (metadata) associated with a post and calls maybe_unserialize() on any value that satisfies is_serialized(). An authenticated user with Contributor level access can create a post, attach a malicious serialized PHP object as metadata, and then trigger the deserialization by accessing the plugin's REST API endpoint for that post.

2. Attack Vector Analysis

• Endpoint: GET /wp-json/post-duplicator/v1/post-data/(?P<id>\d+)
• Vulnerable Parameter: The values of post metadata (retrieved via get_post_custom()) for the post specified by the id parameter.
• Authentication: Authenticated (Contributor+). The user must have permission to duplicate the post, which typically includes any post they have authored.
• Preconditions:
  1. The attacker must be able to add or edit post metadata (standard for Contributors on their own posts).
  2. The attacker must obtain a valid wp_rest nonce to interact with the WordPress REST API.

3. Code Flow

1. Entry Point: The REST route post-duplicator/v1/post-data/(?P<id>\d+) is registered in includes/api.php (line 12) with the callback Mtphr\PostDuplicator\get_post_data.
2. Permission Check: get_post_data_permissions (line 80) is called. It verifies the post exists and checks user_can_duplicate($post).
3. Data Retrieval: get_post_data (line 104) is executed. It calls get_post_custom($post_id) (line 143) to retrieve all metadata for the post.
4. Iteration: The code loops through each meta key and value (lines 146-156).
5. Vulnerable Logic:
   • At line 163, it checks: if ( is_serialized( $value ) ).
   • If true, at line 165, it calls: $unserialized = maybe_unserialize( $value );.
6. Sink: maybe_unserialize() (a wrapper for unserialize()) processes the untrusted string from the database, triggering the PHP Object Injection.
7. Response: The code then checks is_object($unserialized) (line 169) and, if true, sets the type to 'object' and JSON-encodes the object for the response (line 171).

4. Nonce Acquisition Strategy

The REST API endpoint requires a wp_rest nonce for authenticated requests.

1. Identify Script Loading: The plugin enqueues its duplication interface scripts on the post list page (edit.php) for supported post types.
2. Access Admin Area: Log in as the Contributor and navigate to /wp-admin/edit.php.
3. Extract Nonce: Use browser_eval to extract the WordPress standard REST nonce from the wpApiSettings object:
   • JS Variable: window.wpApiSettings.nonce
   • Alternative: If the plugin localizes its own nonce, it would likely be found in a variable like window.postDuplicatorData.nonce (though standard wp_rest is used by the register_rest_route default).

5. Exploitation Strategy

1. Setup Post: Create a post as the Contributor and add a meta field containing a serialized object.
2. Obtain Nonce: Extract the wp_rest nonce from the WordPress dashboard.
3. Trigger Exploit: Send a GET request to the vulnerable REST endpoint.

Step-by-Step Execution:

1. Login: Log in as a Contributor user.
2. Inject Metadata: Use WP-CLI to add a serialized object to a post owned by the Contributor:

   wp post meta add <POST_ID> "exploit_field" 'O:8:"stdClass":0:{}'
   

3. Capture Nonce:
   • Navigate to http://localhost:8080/wp-admin/edit.php.
   • Run browser_eval("window.wpApiSettings.nonce").
4. Send Request:
   • Use http_request to call the endpoint:
     • URL: http://localhost:8080/wp-json/post-duplicator/v1/post-data/<POST_ID>
     • Headers: X-WP-Nonce: <NONCE_VALUE>
     • Method: GET
5. Analyze Response: Observe the customMeta array in the JSON response.

6. Test Data Setup

• User: Role contributor, username exploit_user.
• Post: A standard post created by exploit_user.
• Metadata:
  • Key: test_object_injection
  • Value: O:8:"stdClass":0:{} (A simple standard class object).

7. Expected Results

• Success Indicator: The REST API response (200 OK) will contain a JSON object. Inside the customMeta array, an entry for test_object_injection will have:
  • "type": "object"
  • "isSerialized": true
  • "value": "{}"
• Verification: The fact that the type returned is "object" confirms that maybe_unserialize() successfully transformed the string 'O:8:"stdClass":0:{}' into a PHP object. If it had failed or not run, the type would be "string".

8. Verification Steps

1. Check Logs: Check the PHP error logs for any notices or errors if using a more complex (non-existent) class (e.g., O:15:"NonExistentClass":0:{}).
2. Response Inspection: Verify the JSON response structure:

   {
     "taxonomies": [...],
     "customMeta": [
       {
         "key": "test_object_injection",
         "value": "{}",
         "type": "object",
         "isSerialized": true,
         "originalValue": "O:8:\"stdClass\":0:{}"
       }
     ]
   }
   

3. Database Confirmation: Use wp post meta get <POST_ID> test_object_injection to confirm the raw string in the database matches the injected payload.

9. Alternative Approaches

If the post-data endpoint is inaccessible, the post-full-data endpoint (also in api.php) follows a similar logic and can be used as a fallback:

• Endpoint: GET /wp-json/post-duplicator/v1/post-full-data/(?P<id>\d+)
• Logic: Calls get_post_full_data, which likely also processes custom meta to provide a full preview of the post being duplicated.