Awesome Support – WordPress HelpDesk & Support Plugin <= 6.3.6 - Missing Authorization to Unauthenticated Role Demotion

Vulnerability Summary

The Awesome Support plugin (versions <= 6.3.6) contains a critical authorization bypass in the wpas_do_mr_activate_user function. This function is intended to allow administrators or authorized personnel to manually activate users who have registered via the support portal.

However, the function fails to implement any capability checks (e.g., current_user_can( 'manage_options' )), relying solely on a nonce for security. Due to a nonce reuse vulnerability, the nonce generated for unauthenticated users on the public registration or ticket submission pages is part of the same "namespace" (action string) as the one used for the privileged mr_activate_user action. Consequently, an unauthenticated attacker can obtain a valid nonce from the frontend and use it to trigger the user activation logic against an existing Administrator account, which forces the account's role to be demoted to the plugin's default "Client" role.

Attack Vector Analysis

• Endpoint: The vulnerability is triggered via a GET request to the WordPress frontend (any page) with specific query parameters.
• Vulnerable Action: wpas-do=mr_activate_user
• Parameters:
  • wpas-do: Set to mr_activate_user.
  • user_id: The ID of the user to demote (typically 1 for the primary administrator).
  • _wpnonce: A valid WordPress nonce obtained from the frontend.
• Authentication: None required (Unauthenticated).
• Preconditions:
  • The plugin must be active.
  • A public-facing page containing an Awesome Support shortcode (like [ticket_submit] or [ticket_registration]) must be accessible to extract the nonce.

Code Flow

1. Entry Point: The plugin registers a handler (likely hooked to init or template_redirect) that monitors the wpas-do query parameter.
2. Dispatcher: In includes/functions-user.php (or similar), a function like wpas_do_actions() checks if isset( $_GET['wpas-do'] ).
3. Vulnerable Function Call: If wpas-do equals mr_activate_user, it calls wpas_do_mr_activate_user().
4. Missing Check: Inside wpas_do_mr_activate_user():
   • It retrieves $user_id = $_GET['user_id'].
   • It verifies the nonce: wp_verify_nonce( $_GET['_wpnonce'], 'wpas_nonce' ) (or a similar generic action string).
   • Crucially, it skips any current_user_can() check.
5. Sink: It calls wpas_activate_user( $user_id ).
6. Role Demotion: wpas_activate_user() fetches the user object and calls $user->set_role( 'client' ). If the target $user_id is an administrator, their role is immediately changed to client, stripping them of administrative access.

Nonce Acquisition Strategy

The plugin exposes the necessary nonce via wp_localize_script on any page where its support functionality is loaded.

1. Identify Shortcode: The plugin uses [ticket_submit] for ticket submission.
2. Create Trigger Page: Create a public page containing this shortcode to ensure the scripts and nonces are enqueued.
3. Locate JS Object: The plugin typically localizes data into a JavaScript object named wpas_ajax_vars or wpas_ajax.
4. Extract Nonce: Use browser_eval to extract the nonce:
   • Variable: wpas_ajax_vars.nonce or wpas_nonce.
   • Script Handle: wpas_scripts.

Exploitation Strategy

1. Test Data Setup

• Ensure an administrator user exists (default ID 1).
• Create a public page to expose the nonce.

wp post create --post_type=page --post_title="Support" --post_status=publish --post_content='[ticket_submit]'

2. Nonce Extraction

1. Navigate to the /support page using browser_navigate.
2. Execute browser_eval to find the nonce:

// Likely one of these based on plugin version
window.wpas_ajax_vars?.nonce || window.wpas_ajax?.nonce

3. Exploitation Request

Perform an unauthenticated GET request using the http_request tool.

• URL: http://localhost:8888/
• Method: GET
• Query Parameters:
  • wpas-do: mr_activate_user
  • user_id: 1 (The Admin ID)
  • _wpnonce: [EXTRACTED_NONCE]

Example Construction:
GET /?wpas-do=mr_activate_user&user_id=1&_wpnonce=a1b2c3d4e5

4. Expected Response

The server will likely respond with a redirect (302) or a simple "User Activated" message, but the HTTP status code is less important than the side effect in the database.

Expected Results

• The Administrator user (ID 1) will have their role changed from administrator to client.
• The Administrator will no longer be able to access /wp-admin/.

Verification Steps

After sending the exploit request, verify the role change using WP-CLI:

# Check the role of the user with ID 1
wp user get 1 --field=roles

Success Criteria: The command returns client (or the default AS role) instead of administrator.

Alternative Approaches

If wpas-do=mr_activate_user is not accepted via GET, attempt the request as a POST to admin-ajax.php or the homepage, as some WordPress action dispatchers check $_REQUEST.

If the user_id parameter is not honored directly, check if the plugin expects user or id. Based on the vulnerability report, user_id is the confirmed parameter name.

If [ticket_submit] doesn't work, try these alternative shortcodes to trigger script loading:

• [ticket_registration]
• [my_tickets]
• [ticket_list]