AffiliateX <= 1.3.9.3 - Missing Authorization

This exploitation research plan targets CVE-2025-69346, a missing authorization vulnerability in the AffiliateX plugin for WordPress.

The plan focuses on the authenticated bypass where a Subscriber-level user can trigger administrative AJAX actions due to a lack of current_user_can() checks.

---

1. Vulnerability Summary

The AffiliateX plugin (versions <= 1.3.9.3) registers AJAX handlers that perform sensitive operations (likely settings updates or plugin configuration) but fails to implement proper capability checks. While the handlers might verify a nonce, the nonce is often exposed to all authenticated users in the WordPress admin dashboard (including Subscribers accessing profile.php), allowing them to perform actions intended for Administrators.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Vulnerable Action: affiliatex_save_settings (inferred based on plugin functionality and common patterns in this version range).
• Payload Parameter: settings_data (array or serialized string) or specific setting keys.
• Authentication: Subscriber-level credentials.
• Preconditions: The plugin must be active. The attacker must be logged in as a Subscriber.

3. Code Flow (Inferred)

1. Entry: A Subscriber sends a POST request to admin-ajax.php with action=affiliatex_save_settings.
2. Hook Registration: The plugin registers the action:
   add_action( 'wp_ajax_affiliatex_save_settings', array( $this, 'save_settings' ) );
3. Vulnerable Function: The save_settings function is called.
4. Authorization Failure: The function performs a check_ajax_referer (which passes if the Subscriber has the nonce) but omits if ( ! current_user_can( 'manage_options' ) ) wp_die();.
5. Sink: The function processes $_POST data and calls update_option(), allowing the Subscriber to change plugin configurations.

4. Nonce Acquisition Strategy

The plugin likely enqueues its admin scripts for all users in the admin area. Subscribers can access wp-admin/profile.php, which loads the standard WordPress admin header and any globally enqueued plugin scripts.

1. Identify Localization: Look for the localized JavaScript object. Common names for AffiliateX: affiliatex_admin, affiliatex_vars, or afx_params.
2. Creation of Page: If the scripts aren't in profile.php, we may need to check if they load on the frontend. If not, we will assume they load for any user in wp-admin.
3. Extraction:
   • Navigate to /wp-admin/profile.php as a Subscriber.
   • Run browser_eval("window.affiliatex_admin?.nonce") or browser_eval("window.afx_params?.security").
   • Verification: Check the source code for wp_localize_script.

5. Exploitation Strategy

We will attempt to modify a plugin setting that affects site behavior or allows for further escalation (like an XSS via an "Affiliate Disclaimer" setting).

• Step 1: Authenticate as a Subscriber using wp_cli.
• Step 2: Retrieve the AJAX nonce by navigating the browser to /wp-admin/profile.php.
• Step 3: Use http_request to send the unauthorized update.

Request Details:

• Method: POST
• URL: http://localhost:8080/wp-admin/admin-ajax.php
• Headers: Content-Type: application/x-www-form-urlencoded
• Body:

  action=affiliatex_save_settings&security=[NONCE]&settings_data[affiliate_disclaimer]=<script>alert('XSS')</script>&settings_data[amazon_api_key]=MALICIOUS_KEY
  

  (Note: Parameters names like security and settings_data are inferred and should be verified via grep on the source code if available.)

6. Test Data Setup

1. Plugin Installation: Ensure AffiliateX <= 1.3.9.3 is installed and active.
2. User Creation:
   wp user create attacker attacker@example.com --role=subscriber --user_pass=password
3. Initial State: Check existing settings to compare after exploitation.
   wp option get affiliatex_settings

7. Expected Results

• The admin-ajax.php response should be a JSON success message (e.g., {"success":true}).
• The WordPress database should reflect the modified settings.
• An administrator visiting the AffiliateX settings page would see the injected data (potential Stored XSS).

8. Verification Steps

1. Check DB via CLI:
   wp option get affiliatex_settings
2. Verify Setting Value: Confirm the affiliate_disclaimer or relevant key matches the injected payload.
3. Log Check: Verify that no "Permissions Error" was triggered.

9. Alternative Approaches

If affiliatex_save_settings is not the correct action:

1. Grep for AJAX actions:
   grep -rn "wp_ajax_" wp-content/plugins/affiliatex/
2. Analyze the handlers: Look for any handler in the results that lacks current_user_can. Common targets: affiliatex_import_products, affiliatex_clear_log, affiliatex_license_activate.
3. Bypass Check: If check_ajax_referer is also missing, the exploit becomes unauthenticated if the action is also registered via wp_ajax_nopriv_. If it is registered via wp_ajax_ only, it remains a Subscriber+ exploit.