Exploitation Research Plan: CVE-2026-32513 (JS Archive List Object Injection)

1. Vulnerability Summary

The JS Archive List plugin (versions <= 6.1.7) is vulnerable to PHP Object Injection via the deserialization of untrusted user input. The vulnerability likely resides in a REST API endpoint or an AJAX handler that processes block attributes. Specifically, the plugin's Gutenberg block (js-archive-list/archive-widget) sends its configuration (attributes) to the server to fetch archive data. If the server-side logic applies unserialize() or maybe_unserialize() to any of these attributes (most likely the categories array or a legacy configuration string) without proper validation, an authenticated attacker with Contributor-level permissions can inject a PHP POP chain.

2. Attack Vector Analysis

• Endpoint: WordPress REST API /wp-json/jalw/v1/archive (inferred from build/index.js).
• Vulnerable Parameter: categories (or potentially config if attributes are passed as a single string).
• Authentication: Authenticated (Contributor+). Contributors can access the Gutenberg editor, which triggers the REST API calls used by the block.
• Preconditions: The attacker must have a valid login with at least edit_posts capability (Contributor).

3. Code Flow

1. Frontend Trigger: In the Gutenberg editor, the JsArchiveList component (build/index.js) calls the loadYears(config) function.
2. API Call: This function uses wp-api-fetch to send a request to /jalw/v1/archive.
3. Server-Side Registration: The plugin registers this route using register_rest_route( 'jalw/v1', '/archive', ... ) (likely in a file like includes/api.php or the main plugin file).
4. Vulnerable Sink: The callback function for this route (e.g., get_archive_data) retrieves parameters from the $request.
5. Deserialization: The code likely performs a check like:

   $categories = $request->get_param('categories');
   if (is_string($categories)) {
       $categories = unserialize($categories); // SINK
   }
   

   Or uses maybe_unserialize() on a parameter that the attacker can provide as a serialized string.

4. Nonce Acquisition Strategy

The REST API endpoint requires a wp_rest nonce for authentication. This nonce is typically available in the WordPress admin dashboard for any logged-in user.

1. Access Editor: Log in as a Contributor and navigate to the "New Post" page (/wp-admin/post-new.php).
2. Extract Nonce: The wp_rest nonce is localized in the wpApiSettings JavaScript object.
3. Agent Tooling:
   • Use browser_navigate to go to http://localhost:8080/wp-admin/post-new.php.
   • Use browser_eval to extract the nonce:

     window.wpApiSettings.nonce
     

5. Exploitation Strategy

Step 1: Discover the exact REST parameter

The researcher should first confirm the REST API structure by inspecting the plugin's registration of jalw/v1/archive.

grep -rn "register_rest_route" . --include="*.php"

Step 2: Craft Payload

Since no POP chain is present in the plugin, we use a generic "check" payload to confirm the injection. If a specific chain is required for RCE, common WordPress core chains (like WP_HTML_Token in newer versions or Requests_Utility_FilteredIterator) can be attempted.

Confirming Payload:
O:8:"stdClass":0:{} (A simple standard class object).

Step 3: Execute Request

Send an authenticated request to the REST API with the serialized payload.

HTTP Request (via http_request tool):

• Method: GET (or POST if the route requires it)
• URL: http://localhost:8080/wp-json/jalw/v1/archive?categories=O:8:"stdClass":0:{}
• Headers:
  • X-WP-Nonce: [EXTRACTED_NONCE]
  • Cookie: [CONTRIBUTOR_COOKIES]

6. Test Data Setup

1. User Creation: Create a user with the contributor role.

   wp user create attacker attacker@example.com --role=contributor --user_pass=password
   

2. Post Context: As the contributor, create a draft post to ensure the editor environment is active.

   wp post create --post_type=post --post_status=draft --post_author=[ATTACKER_ID] --post_title="Exploit Test"
   

7. Expected Results

• Success Criteria: The server processes the request. If a POP chain is used that triggers an observable effect (e.g., creating a file or sending a DNS request), that effect is observed.
• Error Side-Effect: If unserialize() is called on an invalid object, PHP may throw a notice or warning. If a valid object is injected, the REST response might return an error if the code expects an array but receives an object (e.g., foreach() argument must be of type array).

8. Verification Steps

1. Log Analysis: Check the PHP error logs for unserialize() errors or signs of object instantiation.

   tail -f /var/www/html/wp-content/debug.log
   

2. Dynamic Analysis: Use a payload that triggers a recognizable function (if a chain is found) or use the http_request tool to monitor the response status. A 500 Internal Server Error referencing a "broken object" or "class not found" often confirms deserialization was attempted.

9. Alternative Approaches

If the REST API does not directly expose the vulnerability:

1. Block Rendering: Contributors can save posts with blocks. If the render_callback for the archive-widget block uses unserialize on attributes, the attacker can save a post containing:

   <!-- wp:js-archive-list/archive-widget {"categories":"O:8:\"Payload\":0:{}"} /-->
   

   And then view the post (or the preview) to trigger the injection.
2. AJAX: Check for wp_ajax_ actions registered by the plugin using:

   grep -rn "wp_ajax" . --include="*.php"
   

   And check if those handlers process attributes.