Email Encoder – Protect Email Addresses and Phone Numbers <= 2.4.4 - Authenticated (Contributor+) Stored Cross-Site Scripting via eeb_mailto Shortcode

This research plan targets a Stored Cross-Site Scripting (XSS) vulnerability in the Email Encoder – Protect Email Addresses and Phone Numbers plugin. The vulnerability allows a Contributor-level user to inject arbitrary JavaScript via the [eeb_mailto] shortcode.

1. Vulnerability Summary

• Vulnerability: Stored Cross-Site Scripting (XSS)
• Component: eeb_mailto shortcode handler.
• Affected Versions: <= 2.4.4
• Mechanism: The plugin fails to sanitize or escape attributes passed to the [eeb_mailto] shortcode, specifically the display attribute (and potentially extra_attrs). When the plugin "encodes" the email to protect it from bots (often using JavaScript document.write or similar methods), it includes the malicious payload in the output without sufficient filtering.

2. Attack Vector Analysis

• Endpoint: WordPress Post Editor (via wp-admin/post-new.php or REST API).
• Action: Creating or updating a post/page containing the [eeb_mailto] shortcode.
• Role Required: Contributor or higher (any role capable of using shortcodes).
• Payload Parameter: Shortcode attributes (e.g., display, extra_attrs).
• Preconditions: The plugin must be active. The default protection method (with_javascript) is typically the most susceptible to XSS in this context.

3. Code Flow

1. Entry Point: A user with Contributor permissions saves a post containing: [eeb_mailto email="test@example.com" display="<img src=x onerror=alert(1)>"].
2. Registration: The shortcode is registered in Legacy\EmailEncoderBundle\Email_Encoder_Settings via the $template_tags array (mapping eeb_mailto to template_tag_eeb_mailto).
3. Execution: When the post is rendered, WordPress calls the handler. According to core/includes/functions/template-tags.php, this calls EEB()->functions->eeb_mailto( ...$args ).
4. Processing (Inferred): The Functions::eeb_mailto method processes the attributes. If the display attribute is not escaped using esc_html() or wp_kses(), the raw HTML is carried into the protection logic.
5. Sink: The logic (similar to the AJAX handle() method in class-email-encoder-bundle-ajax.php) constructs an <a> tag:
   $link = '<a href="mailto:' . $email . '" ...>' . $display . '</a>';
6. Protection Layer: If the "Protect using Javascript" method is active, this $link string is passed to an encoder. Many encoders in this plugin simply obfuscate the string and use a JS-based decoder on the frontend.
7. Execution: When a victim (e.g., Admin) views the post, the JS decoder reconstructs the $link and inserts it into the DOM, executing the onerror payload.

4. Nonce Acquisition Strategy

This vulnerability is triggered by saving a post, which uses standard WordPress core nonces for the Gutenberg editor or Classic editor.

• The PoC agent does not need to extract a plugin-specific nonce to exploit the shortcode.
• The agent should use wp-cli to create the post, which bypasses the need for manual nonce management in the browser.

5. Exploitation Strategy

1. Authentication: Login as a user with the Contributor role.
2. Payload Injection: Create a new post containing the malicious shortcode.
   • Payload 1 (Tag-based): [eeb_mailto email="attacker@example.com" display="<img src=x onerror=alert(window.origin)>"]
   • Payload 2 (Attribute Breakout): [eeb_mailto email="attacker@example.com" extra_attrs='onmouseover=alert(1)']
3. Trigger: As an Administrator, navigate to the newly created post on the frontend.
4. Observation: Verify that the JavaScript executes in the Admin's browser context.

6. Test Data Setup

1. Target User: Create a contributor user:
   wp user create attacker attacker@example.com --role=contributor --user_pass=password123
2. Malicious Post: Use WP-CLI to create the post as the contributor:

   wp post create --post_type=post --post_status=publish --post_title="Contact Us" \
     --post_content='Please contact us at: [eeb_mailto email="test@example.com" display="<img src=x onerror=alert(document.domain)>"]' \
     --post_author=$(wp user get attacker --field=ID)
   

3. Plugin Config: Ensure the default "Protect emails using: automatically the best method (including javascript)" is selected in settings (this is the default state).

7. Expected Results

• The shortcode should be rendered by the plugin.
• The HTML source of the page will contain the encoded version of the link.
• Upon page load, the plugin's JavaScript will decode the payload.
• The browser will attempt to render the <img> tag with an invalid src, triggering the onerror event and showing an alert box with the domain.

8. Verification Steps

1. Check Post Content:
   wp post get <POST_ID> --field=post_content
2. Examine Frontend Output: Use the http_request tool to fetch the post URL and check for the obfuscated string or the injected payload:

   # Look for the encoded snippet or evidence of the encoder JS
   http_request http://localhost:8080/?p=<POST_ID>
   

3. Verify Execution: Use browser_navigate to the post URL and check for the alert or presence of the injected element in the DOM using browser_eval.

9. Alternative Approaches

• Method Obfuscation: If the default JS method is patched, try switching the plugin settings to char_encode or without_javascript via wp option update WP_Email_Encoder_Bundle_options ... to see if the display attribute remains unescaped in other protection modes.
• Shortcode Content: Test if the shortcode supports a content block instead of an attribute: [eeb_mailto email="..."]<script>alert(1)</script>[/eeb_mailto].
• AJAX Endpoint: While the description focuses on the shortcode, the AJAX handler eeb_get_email_form_output in class-email-encoder-bundle-ajax.php uses wp_kses_post on eebDisplay. If the shortcode handler omits this check entirely, that confirms the source of the vulnerability.